github issues 是可讨论、可追踪、可关闭的问题载体，非待办清单；应仅记录需多人确认、有明确输入/输出或引发代码变更的事项，如阻塞点、设计分歧、兼容性方案等。
GitHub Issues 不是待办清单，别直接当任务看
Issues 的本质是「可讨论、可追踪、可关闭的问题载体」，不是 Trello 或 Notion 那种纯任务板。直接往里塞 今天改个按钮颜色 这类琐事，很快会淹没真正需要协作的阻塞点或设计分歧。
实操建议：
- 只用 Issues 记录需要多人确认、有明确输入/输出、或可能引发代码变更的事项——比如
登录页 SSR 渲染后 JS 事件丢失、API v2 返回字段兼容性方案讨论 - 单行命令级操作（如
git checkout -b feat/search）不建 Issue；但“搜索功能要不要支持模糊匹配”这种决策点，必须建 Issue 并附上对比数据 - 标题别写
修复 bug，要具体到现象和环境：Android Chrome 122 下 <code>useInfiniteScroll触发两次 loadMore
Label 要少而准，别堆满「bug」「enhancement」「help wanted」
默认三个 label 够用，但团队一多就失效。关键是用 label 表达「下一步动作」，而不是分类归档。
实操建议：
- 保留
bug、needs-design、blocked这三类——它们直接对应「谁该介入」：blocked意味着 PR 卡在外部依赖，needs-design表示前端等 UI 稿，不是「等设计师回复」而是「没稿不能开工」 - 删掉
help wanted：开源项目才需要它，内部项目用 assignee 和 milestone 更有效 - 避免
low-priority这种 label：它只会让 Issue 永久沉底；真低优先级就关掉，或移到 Projects 看板里「Backlog」列
PR 关联 Issues 时，别只靠「closes #123」自动关闭
GitHub 自动关闭 Issue 的前提是 PR 合并进默认分支（通常是 main 或 master），如果合进 dev 或 release/1.2，Issue 依然开着——很多人卡在这儿，以为“已修复”，其实没生效。
实操建议：
- 在 PR 描述里明确写：
Closes #123（不是Fixes #123，后者不触发关闭） - 确认 PR 目标分支是默认分支；如果不是，手动关闭 Issue，并在评论里写：
Merged into <code>release/1.2, will land in next prod deploy - 如果 Issue 涉及多个 PR（比如先修后端再改前端），用
Relates to #123，别强行 close
用 Projects（新看板）补 Issues 的短板，但别替代分支策略
Issues 本身没有状态流转能力，Projects 看板能补上「To Do / In Progress / Review / Done」，但它不解决 Git 分支混乱问题——有人把所有开发都堆在 main 上，靠 Projects 标记「In Progress」，结果冲突频发。
实操建议：
- Projects 只做可视化追踪，不替代分支命名规范：
feat/login-sso、fix/header-zindex必须严格执行 - 每个 Project 列对应一个明确动作：「Review」列只放已标记
ready-for-reviewlabel 且 CI 通过的 PR，不是「我写完了」就拖进去 - 别在 Projects 里建子任务：Issue 本身支持 comment + task list（- [ ] xxx），比跨看板跳转更轻量
最常被忽略的是：Issues 的生命周期和代码部署节奏必须对齐。一个标为 done 的 Issue，如果对应代码还没上预发环境，那它就不算 done。
