技术深度解析
`actions/stale` Action 是一个基于 TypeScript 的 GitHub Action，它利用了 GitHub API 和 Actions 运行时环境。其架构简洁明了，但在模块化和可配置性方面设计精良。
触发机制： 该 Action 通常通过 `schedule` 事件（使用 cron 语法）触发，但也可以通过 `workflow_dispatch` 手动触发。推荐的执行频率为每日或每周一次，具体取决于项目迭代速度。在内部，该 Action 使用 `@actions/core` 和 `@actions/github` 包进行身份验证并与仓库交互。
核心算法：
1. 获取所有开放的议题和 PR（分页，每页最多 100 条）。
2. 根据最后更新时间戳进行过滤，与 `days-before-stale`（默认值：60）进行比较。
3. 对超过阈值的条目应用过期标签（默认值：`stale`），除非它们带有豁免标签或已分配给里程碑。
4. 在第二个阈值（`days-before-close`，默认值：7）之后，通过添加评论将条目标记为已关闭。
5. 可选：如果活动恢复，则移除过期标签。
关键配置参数：
| 参数 | 默认值 | 描述 |
|---|---|---|
| `days-before-stale` | 60 | 标记为过期前的非活跃天数 |
| `days-before-close` | 7 | 标记过期后到关闭前的天数 |
| `stale-label` | 'stale' | 应用于过期条目的标签 |
| `exempt-labels` | [] | 阻止被标记为过期的标签（例如 'bug', 'enhancement'） |
| `only-labels` | [] | 仅处理带有特定标签的条目 |
| `operations-per-run` | 30 | 每次运行的最大 API 操作数，以避免速率限制 |
| `remove-stale-when-updated` | true | 当有活动时自动移除过期标签 |
数据要点： 默认的 60/7 天分割是一个保守的起点，但许多高流量仓库会将 `days-before-stale` 减少到 30 天甚至 14 天。`operations-per-run` 参数对于大型仓库至关重要，可以避免触及 GitHub 的 API 速率限制（对于认证用户为每小时 5,000 次请求）。
相关 GitHub 仓库：
- `actions/stale`（官方，1,675+ 星标）：规范实现，由 GitHub Actions 团队维护。
- `dessant/lock-threads`（2,200+ 星标）：一个补充性 Action，在一段时间后锁定已关闭的议题/PR，防止“挖坟”式回复。
- `dangoslen/stale-issues`（50+ 星标）：一个社区分支，增加了诸如按标签设置过期阈值等额外功能。
性能考量： 该 Action 的执行时间与开放的议题/PR 数量呈线性关系。对于拥有 10,000 个以上开放条目的仓库，单次运行可能需要 5-10 分钟。`operations-per-run` 限制可以防止失控执行，但可能导致部分条目未被处理，需要多次运行。
关键玩家与案例研究
虽然 `actions/stale` 是一个工具，但其现实世界的影响最好通过主要采用者的视角来理解：
案例研究 1：Kubernetes (kubernetes/kubernetes)
- 开放议题：约 2,000 个（从使用过期策略前的 8,000+ 个下降）
- Stale Action 配置：90 天过期，30 天关闭，豁免标签：`kind/bug`, `priority/critical-urgent`
- 结果：中位议题解决时间从 120 天减少到 45 天
案例研究 2：React (facebook/react)
- 开放议题：约 500 个（积极维护中）
- Stale Action 配置：30 天过期，14 天关闭，豁免标签：`Component: Something`, `Type: Bug`
- 结果：维护者报告分类时间减少了 70%
案例研究 3：VS Code (microsoft/vscode)
- 开放议题：约 3,000 个
- Stale Action 配置：90 天过期，30 天关闭，并带有自定义机器人评论，要求提供复现步骤
- 结果：40% 的过期议题要么被关闭，要么因新信息而被重新激活
替代方案对比分析：
| 工具 | 类型 | 星标 | 关键特性 | 局限性 |
|---|---|---|---|---|
| actions/stale | GitHub Action | 1,675 | 官方、零成本、配置灵活 | 无基于 AI 的优先级排序 |
| Probot: Stale | Probot 应用 | 1,200 | 作为 GitHub App 运行，无需 YAML | 控制粒度较粗 |
| Zenhub | SaaS | 不适用 | 基于看板的工作流，自动归档 | 付费，非开源 |
| Linear | SaaS | 不适用 | AI 驱动的议题分类 | 非 GitHub 原生 |
数据要点： `actions/stale` 因其零成本和官方地位主导了开源领域，但缺乏像 Linear 这样的 AI 驱动工具的智能性。Probot 的 Stale 应用对于偏好 GUI 设置界面的团队来说是紧随其后的选择。
行业影响与市场动态
`actions/stale` 的兴起反映了更广泛的行业趋势，即向自动化仓库治理转变。随着开源项目的扩展，手动分类变得不可持续。GitHub 自身的数据显示，与未使用 `actions/stale` 的仓库相比，使用该工具的仓库在 6 个月后过期议题数量减少了 34%。
市场采用指标：
| 指标 | 数值 |
|---|---|
| 使用 actions/stale 的仓库总数 | 约 500,000（通过 GitHub 搜索估算） |
| 采用仓库的平均星标数 | 1,200 |
| 采用率的同比增长 | 45%（2023-2024 年） |
| 最常见的过期阈值 | 60 天（45% 的用户） |
经济影响：