维护开源仓库这几年我越来越觉得 Issue 列表像一面照妖镜一个项目缺不缺规范看提上来的 Issue 是什么画风就知道。早期我的仓库里常见的是“这个 bug 怎么修”“程序崩了帮忙看看”这类一句话 Issue既没有环境信息也没有复现步骤来来回回追问几轮时间全耗在沟通上。后来我老老实实把 GitHub Issue Template 配齐最近又全面切到新版 Issue Forms也就是用 bug_report.yml、feature_request.yml 这类 YAML 文件定义的模板再用一个 config.yml 统一管理空白 Issue 和外部联系入口沟通成本才真正降下来。这篇文章不讲虚的就以 bug_report.yml 和 config.yml 为主线把目录结构、字段设计、完整示例、实测流程和排查经验一次讲透。不管你是刚建仓库的新手还是被无效 Issue 折磨已久的老维护者看完都能直接照着自己仓库改。1. 为什么说 Issue 模板是开源仓库的“第一道防线”很多人把模板理解成“一个 Markdown 文件”这没错但格局小了。Issue 模板的本质是帮你把提交问题的成本从维护者转移给提报人。你不配置模板成本就落在你身上——每条 Issue 都要靠追问去补全信息你配置好模板成本就前置到提报人那里他花三分钟把字段填完你拿到手就是一份可以直接开工的工单。1.1 没有模板的仓库维护者都在补什么课我给你还原一个真实场景用户在某个周四下午提了一条 Issue“登录接口报错帮我看看”。你看到这条消息心里立刻冒出好几个待确认项他用的什么版本什么浏览器报错发生在请求环节还是渲染环节控制台有没有日志是不是我们已知的某个历史问题你逐条回复对方隔天才回一句“我用的是最新版”。再一问日志又没了下文。一个本来可能两分钟定位的问题硬生生拖了两三天。更麻烦的是这种低信息量 Issue 会在列表里持续占据空间。你不敢轻易关掉因为万一里面真有 bug 呢于是它就一直挂在那里像一根刺。维护者每天打开仓库看到一堆“待补充信息”的 Issue心理压力是很大的。我还见过更极端的例子有人提完 Issue 后自己都忘了正文里写过什么因为你让他“把完整报错贴一下”结果他把报错复制到了标题里正文只剩“求帮助”三个字。这不是用户坏而是仓库没有给他们一个“标准动作”他们只能用自己想当然的方式提。1.2 模板到底能帮我们自动完成哪些事配置好的 Issue 模板不只是给用户看的一段说明文字。它至少能干三件实事第一规范提报格式。你可以把运行环境、版本号、复现步骤、预期结果这些字段固定下来用户按字段填信息完整度大幅提升。第二自动打标签和指派人。YAML 头部里写了 labels 和 assignees用户创建 Issue 时仓库会自动把这些元数据挂上去省去维护者手动分类的时间。第三和后续自动化流程衔接。比如模板字段里带上了“项目版本”将来你写脚本统计某个版本上的 Bug 密度、复现率时数据是现成的如果再用 GitHub Actions 做 Issue 自动分流每个模板对应的 label 就是流量的入口标记。所以我的感受是模板不是给用户填的而是给维护者自己省时间用的。你把规则立起来后面的分类、统计、路由才能谈得上。2. 选型老式 Markdown 模板和 YAML 表单怎么权衡GitHub 现在支持两种模板方式一种是历史悠久的 Markdown 模板另一种是新版 Issue FormsYAML 驱动。这不是简单的“新替代旧”两者各有适用场景。配置之前先把这笔账算清楚。2.1 老式写法还是能用但已经不够用老式模板就是在一个以 .md 结尾的文件头部写一段 YAML front matter正文写 Markdown里面列一串“提问清单”。用户点击模板后GitHub 会按标题预填 Issue然后把 Markdown 正文原样带入编辑框。它最大的问题在于正文里的所有问题都只是“参考文本”用户完全可以全选删除甚至只留一个“同上”提交上来。你没法强制他填写任何内容。从维护体验上说老式模板适合非常简单的仓库。比如个人项目、插件仓库、明确知道用户群都是开发者的工具类项目。你可以在模板里把话写得客气一点依赖用户的自觉性。但一旦仓库用户基数变大自觉这种东西就不太可靠了。我在一个几百星的项目上观察过老式模板下大约有三成用户会保留模板结构剩下的会各显神通地简化。所以它不是不能用而是别对它抱太多期望。2.2 新一代 Issue Forms 到底强在哪Issue Forms 的底层也是一份 YAML 文件但它的 body 字段会被 GitHub 渲染成真正的 Web 表单。文本输入框就是输入框下拉框就是下拉框复选框就是复选框必填项就是真的必填项。这意味着用户几乎不可能绕开你的问题清单。他填完环境信息才能提交没填版本号就过不了校验。提交之后GitHub 会把表单内容拼装成一段结构清晰的 Issue 正文每个字段都有 label 和对应内容。维护者打开 Issue一眼就能看到缺什么、有什么。除了强制填写表单还能带来更细的字段类型设计。比如用 input 类型接短文本版本号、浏览器型号用 textarea 接长篇内容复现步骤、完整报错用 dropdown 处理有限选项影响范围、所属模块用 checkboxes 做提交前确认清单。这种精细度是 Markdown 模板完全做不到的。2.3 我的选择建议什么时候用哪种我不建议“一刀切都换成 YAML”。给你一个判断标准对比维度老式 Markdown 模板新一代 Issue Forms字段强制程度弱完全靠自觉强字段级校验支持字段类型只有 Markdown 文本input、textarea、dropdown、checkboxes配置成本很低一个文件搞定中等需要懂 YAML 语法对新人友好度高像聊天记录略高像填调查问卷适合场景小仓库、内部项目、模板只是参考用户量大、需要结构化信息、要接自动化如果是刚起步的仓库先用一个简单的 Markdown 模板跑通流程完全没问题。但如果你已经明显感觉到“用户没有按模板填”的挫败感或者你希望未来做 Issue 数据分析那越早迁到 Issue Forms 越好。我自己的做法是新仓库直接上 YAML老仓库从 bug_report 这一个模板开始迁移等稳定后再把 feature request 也迁过去。3. 手把手配置 bug_report.yml现在进入正题。拿一个最典型的模板文件举例bug_report.yml。往下每一步我都会告诉你为什么这么写而不是只丢一个配置模板让你自己抄。3.1 目录结构和文件命名模板文件必须放在仓库的 .github/ISSUE_TEMPLATE/ 目录下。注意这里有两个硬性坑第一目录名是 ISSUE_TEMPLATE全大写不是 issue_template也不是 ISSUE_TEMPLATES第二文件名后缀只能是 .yml 或 .md别写成 bug_report.yml.txt。在网页上创建文件时很多人路径输成.github/issue_template/bug_report.ymlGitHub 会老老实实给你创建一个小写目录结果模板完全不生效排查半天才发现是大小写问题。为什么建议用 .github/ISSUE_TEMPLATE 而不是仓库根目录因为 .github 这个目录本身就是 GitHub 约定俗成的“仓库元信息目录”。未来你要加 PR 模板、社区健康文件、工作流配置都会往 .github 里塞统一放一起不会污染根目录。3.2 front matter 字段和 body 组件逐个拆解一个 bug_report.yml 由两部分组成front matterYAML 头部和 body表单主题。front matter 里的字段控制模板的“身份信息”。name 是必填项会显示在新建 Issue 页面的模板卡片上比如“Bug Report”。description 会作为卡片副标题出现建议写清楚“这个模板用来干什么”避免用户拿 Bug 模板提交功能需求。title 用来预填 Issue 标题我习惯写成[Bug]:让所有 Bug Issue 标题天然带统一前缀。labels 和 assignees 是自动化信息分别指定这个模板创建出来的 Issue 默认贴上哪些标签、指派给谁它们都可以是单个字符串或数组。body 是整个 YAML 文件的核心。它是一个列表每一项代表表单里的一块内容。GitHub 支持五种 typemarkdown、input、textarea、dropdown、checkboxes。具体能力对比如下type渲染效果常用属性是否支持 requiredmarkdown普通提示文本value否input单行文本框label、description、placeholder、value是textarea多行文本框label、description、placeholder、value是dropdown下拉菜单label、description、options、multiple是checkboxes复选框组合label、description、options选项级支持markdown 类型里你可以在 value 中写多行文本注意用 YAML 的块标量|来保留换行。input 适合短字段比如版本号、操作系统textarea 适合复现步骤、完整报错这类长内容dropdown 的 options 必须是数组给用户几个明确选项别让他们自由发挥。checkboxes 的 required 不在 validations 里控制而是在每个选项内部写 required: true。这个特别容易搞混很多人下意识在 checkboxes 上加 validations: required: true结果发现不生效。3.3 可以直接抄的 bug_report.yml 完整示例下面是我的一个实际项目在用的精简版字段、顺序、提示语都调过你可以直接复制再把 assignees 换成自己的账号。name: Bug Report description: 提交一段能稳定复现的 Bug 描述帮助维护者快速定位问题 title: [Bug]: labels: - bug - needs-triage assignees: - your-github-username body: - type: markdown attributes: value: | 感谢你花时间提交 Bug。带 * 的字段必填信息越完整定位越快。 - type: textarea id: bug-description attributes: label: 问题描述 description: 发生了什么实际结果和预期结果分别是什么 placeholder: | 例如点击登录按钮后页面白屏预期应跳转到控制台。 validations: required: true - type: textarea id: repro-steps attributes: label: 复现步骤 description: 尽量一步一步写清楚即使你觉得“太基础”。 placeholder: | 1. 访问项目首页 2. 点击登录按钮 3. 观察页面白屏 validations: required: true - type: input id: project-version attributes: label: 项目版本 description: 你正在使用的版本号可在项目配置文件中查看 placeholder: v1.2.3 validations: required: true - type: input id: environment attributes: label: 运行环境 description: 操作系统、浏览器或运行时版本 placeholder: macOS 14.2 / Chrome 121 / Node 20 validations: required: true - type: dropdown id: impact attributes: label: 影响范围 description: 这个问题影响到了哪些用户 options: - 只有我 - 部分用户 - 所有用户 validations: required: true - type: checkboxes id: confirmation attributes: label: 提交前确认 description: 逐项确认减少维护者来回追问 options: - label: 我已经确认这不是重复的 Issue required: true - label: 我能提供必要的日志或截图 required: false这个模板的设计思路是问题描述和复现步骤必填版本和环境影响必填影响范围用下拉控制让用户从三个选项里选避免写一堆“我觉得影响很大”之类的主观描述。提交前确认清单会在最后给用户一个“冷静检查”的机会这比强制他在正文里写“我已经查过重复”有用得多。3.4 给表单加自动化联动labels、assignees 的玩法很多维护者把 label 当成事后分类工具其实模板阶段就可以把 label 分好。比如 bug_report.yml 的 labels 里放了“bug”和“needs-triage”那么用户提交出来的 Issue 天然带着“待初审”标记。此时你的 GitHub Actions 工作流可以直接监听这个 label 做自动分流比如 bug needs-triage 的 Issue 自动进入某个项目面板feature_request.yml 的 labels 则放进另一个项目轨道。assignees 也是同理。小团队可以指定固定的人接收 Bug Issue哪怕后面再改派也比一个谁都不知道该谁处理的裸 Issue 强。不过要注意assignees 字段是静态的你没法根据表单里某个选项动态指派人。真要做“用户选了模块 A 就 模块 A 维护者”这种效果还是得靠 Actions 脚本去解析 Issue 正文模板负责把数据结构化地提供出来这一步就顺理成章了。4. config.yml 的作用空白 Issue 和联系入口怎么管模板文件负责“提什么”config.yml 负责“哪些能提、提不了时去哪”。它也是一个 YAML 文件放在同一个目录下文件名叫 config.yml。这里的 config.yml 不是数据库中间件那个 config不要看到同名文件就条件反射。4.1 文件位置与基本结构config.yml 的完整路径是 .github/ISSUE_TEMPLATE/config.yml。它的顶层字段只有两个blank_issues_enabled 和 contact_links。一个最基础的写法是blank_issues_enabled: false contact_links: - name: 项目官方文档 url: https://docs.example.com about: 提交 Issue 前请先查阅文档常见问题页面可能已有答案 - name: 社区讨论区 url: https://github.com/你的账号/你的仓库/discussions about: 功能建议、使用疑问、非 Bug 类讨论请前往 Discussions如果你没有创建 config.ymlGitHub 默认允许用户创建空白 Issue也不会显示任何额外联系入口。也就是说Config 文件的本质作用是对“新建 Issue 页面”做定制。4.2 blank_issues_enabled到底该不该留空白入口blank_issues_enabled 设置为 false 后新建 Issue 页面将不再出现“Open a blank issue”入口用户只能从你提供的模板里选。听起来很美好好像能把用户都框进模板。但我踩过一次坑过早关闭空白入口会让一小部分用户因为找不到“不适用任何模板”的选项而产生抵触最后避开你的仓库或者跑到 Discussions 里骂骂咧咧。对刚起步、模板数量还不够丰富的仓库我不建议关当你有至少三四个分类明确、覆盖大部分场景的模板时再考虑关掉也不迟。还有一种思路是保留空白入口但在 config.yml 里把 contact_links 的文档和讨论区做足。这样“用户感觉有地方可去”而不是被逼着乱选模板。实际上大型开源项目也未必关掉空白入口有些仓库就是靠模板做引导同时留一个“其他问题”的空白通道给边缘情况兜底。4.3 contact_links把非 Bug 流量导到该去的地方contact_links 的价值常常被低估。它不参与表单渲染而是显示在新建 Issue 页面下方的“联系链接”区域。比如你的项目有官方文档站有 GitHub Discussions 板块有即时沟通群都可以通过 contact_links 列出来。用户进来第一眼看到模板往下滚看到“如果你只是想问怎么用请看文档”提非 Bug 类 Issue 的概率就会小很多。注意给每个链接写清楚 about 字段它决定链接在页面上显示成什么说明文字。url 必须是可访问的完整地址GitHub 不会帮你校验写错了页面就会挂一个无效链接反而减分。另外contact_links 的 name 不要起得太大比如“帮助中心”这种如果链接背后只是 README 的一句话用户点进去会觉得被戏弄。5. 从零到上线创建、校验、实测一次走通配置模板最怕的是“写的时候很爽提交后没反应”。所以完整流程走一遍把每一步的关键点钉死你也就能少折腾几轮。5.1 通过网页或命令行创建文件最快速的方式是直接在仓库页面点“Add file → Create new file”。路径栏输入.github/ISSUE_TEMPLATE/bug_report.ymlGitHub 会自动创建中间目录。然后粘贴我上面给的 YAML 内容点提交。首次提交可以直接推到主分支模板是即时生效的不像 CI 配置要等工作流跑完。如果你习惯命令行也可以在本地仓库里先建好文件再 push。示例mkdir -p .github/ISSUE_TEMPLATE touch .github/ISSUE_TEMPLATE/bug_report.yml # 编辑文件内容 git add .github/ISSUE_TEMPLATE/ git commit -m docs: add bug report issue form git push origin main无论哪种方式提交后建议立刻去仓库主页看一眼新建 Issue 页面先确认模板卡片出现再点进去看表单渲染。5.2 提交前用 YAML 校验器自检YAML 是个看着简单、实际很娇气的格式。缩进不一致、Tab 和空格混用、特殊符号没加引号都能让文件解析失败。GitHub 不会在你提交的时候弹一个明确报错它只会悄悄让表单不可用非常阴险。我自己的做法是提交前用 Python 快速校验一下。如果你本地有 Python可以跑python -c import yaml,sys; yaml.safe_load(open(bug_report.yml)); print(YAML parse ok)如果没有安装 pyyaml先pip install pyyaml。或者用编辑器里的 YAML 插件保存时会顺手高亮语法错误。校验通过只是第一步字段语义对不对还得靠实测。5.3 实测在仓库中真实走一遍提交流程配置完模板后我强烈建议你自己以普通用户的身份提一条测试 Bug。操作路径是点仓库的 Issues → New issue → 选择 Bug Report 卡片 → 填表单 → 点击提交。此时重点关注几件事第一必填项是否真的拦人。把所有字段都留空直接提交正常情况是 GitHub 会提示校验失败。第二placeholder 和 description 是否足够友好你站在用户视角读一遍看有没有看不懂的术语。第三labels 和 assignees 是否自动挂上创建出来的 Issue 侧边栏应显示 front matter 里写好的标签和指派人。都通过之后把这条测试 Issue 直接关闭并删除避免污染列表。如果你不想在正式仓库折腾可以建一个专用来测试的私有仓库比如 test-issue-templates把同样的文件传上去点一遍。模板的生效机制与仓库大小无关私有仓库也能完整验证。实测下来最稳的流程就是先在本地校验 YAML再推到测试仓库确认渲染最后复制到正式仓库。5.4 后续维护模板版本化与迭代节奏模板不是写完就完事的东西。我发现很多仓库的模板三年不更新里面的链接早就失效字段和产品现状也对不上。维护模板的节奏可以跟随版本迭代每次发版调整表单字段时顺手检查模板里的选项是否还准确新增了模块或功能入口就在 dropdown 的 options 里加一项。模板文件本身有 git 历史这给了你天然的版本管理能力。改错了随时能回滚。我建议把模板变更和文档变更放到同一个 commit 里比如这次改了 Bug 模板里的“影响范围”选项提交信息写成“docs: update bug form impact options”将来查起来很清楚。6. 常见问题与排查技巧实录这一节汇总我实际遇到过的坑全部来自真实仓库操作不掺水。6.1 模板提交了表单却一直不出现先检查目录名大小写。ISSUE_TEMPLATE全大写config.yml全小写。再检查文件后缀名.yml不是.yaml的问题不大但如果你写成了bug_report.yml.txtGitHub 完全不认。然后看仓库的 Issues 功能是否被关闭Settings → General → Features → Issues 必须处于开启状态否则模板页面都进不去。最后强制刷新浏览器缓存有时候接口数据没更新你看到的是旧页面。文件放在 .github/ISSUE_TEMPLATE 下如果目录里没有任何模板config.yml 单独存在也是可以的但新建 Issue 页面就不会有模板卡片只显示 config 配置。一般没人这么干提一下避免误解。6.2 表单能显示但提交后内容错乱或字段缺失这类问题多数出在 YAML 的 value 和 placeholder 里。如果你在 value 中写了特殊字符比如以冒号、井号开头的内容YAML 解析时会当成注释或字典结构最好用双引号包起来或者改用|块标量保留原文。比如 placeholder 的字符串里带了:就会让解析直接崩掉。还有一个容易被忽略的地方body 数组里每个元素如果写了重复的 idGitHub 会展示两个同名字段提交时互相覆盖。给每个块一个唯一 id像我在模板示例里那样用 bug-description、repro-steps就不会撞车。6.3 下拉选项、复选项和必填规则失效这通常是语法位置写错了。dropdown 的必填是 validations.requiredcheckboxes 的必填是 options 内部每个选项的 requiredinput 和 textarea 的必填也是 validations.required。一定不要跨类型乱套。另外 dropdown 的 options 不能为空数组至少要给一个选项不然表单没办法渲染。复选项如果想让用户“至少勾选两项”GitHub 原生的 checkboxes 并不支持自定义数量限制只能通过每个选项的 required 做“必须勾这个”级别的控制更复杂的校验需要后续 Actions 处理。还有一点不要把 dropdown 的 options 写得太多超过十项用户在手机上就划得很痛苦。能用五个选项解决的问题别列二十个。6.4 多个模板同时存在时的排序与去重当目录里有多个模板文件GitHub 会按某种顺序把它们列出来通常接近文件名排序。如果你在意顺序可以用数字前缀控制比如01_bug_report.yml、02_feature_request.yml。同时要注意模板之间的边界别让“Bug Report”和“问题反馈”同时存在用户根本分不清。我见过仓库里放了四个模板描述都是“有问题反馈”最后用户随便点一个填维护者还得手动转。模板之间既要有分工又要在 description 里说清边界。比如 bug_report 说“软件表现不符合预期需要修复”feature_request 说“希望增加能力或改进体验”这两句话就能让大多数用户做出正确选择。6.5 多语言仓库与周边工具配合如果你的仓库用多种语言维护比如 README 是英文但用户群里主要是中文使用者我建议建两个模板比如bug_report_en.yml和bug_report_zh.ymlname 和 description 分别用英文和中文写清楚。新建 Issue 页面会同时出现两张卡片用户自然选择看得懂的那个。注意同一个仓库里不要给中文模板挂和英文模板一模一样的 label至少要在 label 上区分语言或渠道否则统计时还得靠正文猜。另外模板配置可以和 PR 模板、贡献指南配合起来。我的仓库里Issue 模板负责接收问题PR 模板负责接收代码CONTRIBUTING.md 里写清楚“提 Issue 前先搜索、按模板填、附上版本信息”三层一起作用仓库才真正像个正规军。这些都没什么高深原理关键是想清楚每个入口承担什么职责用户就不会走错门。最后留一个我自己常用的判断标准当你打开仓库的 Issue 列表不需要点进正文就能从标题和标签上知道这条 Issue 是干什么的、严重程度如何、涉及哪个模块说明模板体系已经合格了。模板不是越多越好覆盖住主要场景、让数据入口整洁比一个月内堆出十个表单文件有意义得多。
维护开源仓库这几年我越来越觉得 Issue 列表像一面照妖镜一个项目缺不缺规范看提上来的 Issue 是什么画风就知道。早期我的仓库里常见的是“这个 bug 怎么修”“程序崩了帮忙看看”这类一句话 Issue既没有环境信息也没有复现步骤来来回回追问几轮时间全耗在沟通上。后来我老老实实把 GitHub Issue Template 配齐最近又全面切到新版 Issue Forms也就是用 bug_report.yml、feature_request.yml 这类 YAML 文件定义的模板再用一个 config.yml 统一管理空白 Issue 和外部联系入口沟通成本才真正降下来。这篇文章不讲虚的就以 bug_report.yml 和 config.yml 为主线把目录结构、字段设计、完整示例、实测流程和排查经验一次讲透。不管你是刚建仓库的新手还是被无效 Issue 折磨已久的老维护者看完都能直接照着自己仓库改。1. 为什么说 Issue 模板是开源仓库的“第一道防线”很多人把模板理解成“一个 Markdown 文件”这没错但格局小了。Issue 模板的本质是帮你把提交问题的成本从维护者转移给提报人。你不配置模板成本就落在你身上——每条 Issue 都要靠追问去补全信息你配置好模板成本就前置到提报人那里他花三分钟把字段填完你拿到手就是一份可以直接开工的工单。1.1 没有模板的仓库维护者都在补什么课我给你还原一个真实场景用户在某个周四下午提了一条 Issue“登录接口报错帮我看看”。你看到这条消息心里立刻冒出好几个待确认项他用的什么版本什么浏览器报错发生在请求环节还是渲染环节控制台有没有日志是不是我们已知的某个历史问题你逐条回复对方隔天才回一句“我用的是最新版”。再一问日志又没了下文。一个本来可能两分钟定位的问题硬生生拖了两三天。更麻烦的是这种低信息量 Issue 会在列表里持续占据空间。你不敢轻易关掉因为万一里面真有 bug 呢于是它就一直挂在那里像一根刺。维护者每天打开仓库看到一堆“待补充信息”的 Issue心理压力是很大的。我还见过更极端的例子有人提完 Issue 后自己都忘了正文里写过什么因为你让他“把完整报错贴一下”结果他把报错复制到了标题里正文只剩“求帮助”三个字。这不是用户坏而是仓库没有给他们一个“标准动作”他们只能用自己想当然的方式提。1.2 模板到底能帮我们自动完成哪些事配置好的 Issue 模板不只是给用户看的一段说明文字。它至少能干三件实事第一规范提报格式。你可以把运行环境、版本号、复现步骤、预期结果这些字段固定下来用户按字段填信息完整度大幅提升。第二自动打标签和指派人。YAML 头部里写了 labels 和 assignees用户创建 Issue 时仓库会自动把这些元数据挂上去省去维护者手动分类的时间。第三和后续自动化流程衔接。比如模板字段里带上了“项目版本”将来你写脚本统计某个版本上的 Bug 密度、复现率时数据是现成的如果再用 GitHub Actions 做 Issue 自动分流每个模板对应的 label 就是流量的入口标记。所以我的感受是模板不是给用户填的而是给维护者自己省时间用的。你把规则立起来后面的分类、统计、路由才能谈得上。2. 选型老式 Markdown 模板和 YAML 表单怎么权衡GitHub 现在支持两种模板方式一种是历史悠久的 Markdown 模板另一种是新版 Issue FormsYAML 驱动。这不是简单的“新替代旧”两者各有适用场景。配置之前先把这笔账算清楚。2.1 老式写法还是能用但已经不够用老式模板就是在一个以 .md 结尾的文件头部写一段 YAML front matter正文写 Markdown里面列一串“提问清单”。用户点击模板后GitHub 会按标题预填 Issue然后把 Markdown 正文原样带入编辑框。它最大的问题在于正文里的所有问题都只是“参考文本”用户完全可以全选删除甚至只留一个“同上”提交上来。你没法强制他填写任何内容。从维护体验上说老式模板适合非常简单的仓库。比如个人项目、插件仓库、明确知道用户群都是开发者的工具类项目。你可以在模板里把话写得客气一点依赖用户的自觉性。但一旦仓库用户基数变大自觉这种东西就不太可靠了。我在一个几百星的项目上观察过老式模板下大约有三成用户会保留模板结构剩下的会各显神通地简化。所以它不是不能用而是别对它抱太多期望。2.2 新一代 Issue Forms 到底强在哪Issue Forms 的底层也是一份 YAML 文件但它的 body 字段会被 GitHub 渲染成真正的 Web 表单。文本输入框就是输入框下拉框就是下拉框复选框就是复选框必填项就是真的必填项。这意味着用户几乎不可能绕开你的问题清单。他填完环境信息才能提交没填版本号就过不了校验。提交之后GitHub 会把表单内容拼装成一段结构清晰的 Issue 正文每个字段都有 label 和对应内容。维护者打开 Issue一眼就能看到缺什么、有什么。除了强制填写表单还能带来更细的字段类型设计。比如用 input 类型接短文本版本号、浏览器型号用 textarea 接长篇内容复现步骤、完整报错用 dropdown 处理有限选项影响范围、所属模块用 checkboxes 做提交前确认清单。这种精细度是 Markdown 模板完全做不到的。2.3 我的选择建议什么时候用哪种我不建议“一刀切都换成 YAML”。给你一个判断标准对比维度老式 Markdown 模板新一代 Issue Forms字段强制程度弱完全靠自觉强字段级校验支持字段类型只有 Markdown 文本input、textarea、dropdown、checkboxes配置成本很低一个文件搞定中等需要懂 YAML 语法对新人友好度高像聊天记录略高像填调查问卷适合场景小仓库、内部项目、模板只是参考用户量大、需要结构化信息、要接自动化如果是刚起步的仓库先用一个简单的 Markdown 模板跑通流程完全没问题。但如果你已经明显感觉到“用户没有按模板填”的挫败感或者你希望未来做 Issue 数据分析那越早迁到 Issue Forms 越好。我自己的做法是新仓库直接上 YAML老仓库从 bug_report 这一个模板开始迁移等稳定后再把 feature request 也迁过去。3. 手把手配置 bug_report.yml现在进入正题。拿一个最典型的模板文件举例bug_report.yml。往下每一步我都会告诉你为什么这么写而不是只丢一个配置模板让你自己抄。3.1 目录结构和文件命名模板文件必须放在仓库的 .github/ISSUE_TEMPLATE/ 目录下。注意这里有两个硬性坑第一目录名是 ISSUE_TEMPLATE全大写不是 issue_template也不是 ISSUE_TEMPLATES第二文件名后缀只能是 .yml 或 .md别写成 bug_report.yml.txt。在网页上创建文件时很多人路径输成.github/issue_template/bug_report.ymlGitHub 会老老实实给你创建一个小写目录结果模板完全不生效排查半天才发现是大小写问题。为什么建议用 .github/ISSUE_TEMPLATE 而不是仓库根目录因为 .github 这个目录本身就是 GitHub 约定俗成的“仓库元信息目录”。未来你要加 PR 模板、社区健康文件、工作流配置都会往 .github 里塞统一放一起不会污染根目录。3.2 front matter 字段和 body 组件逐个拆解一个 bug_report.yml 由两部分组成front matterYAML 头部和 body表单主题。front matter 里的字段控制模板的“身份信息”。name 是必填项会显示在新建 Issue 页面的模板卡片上比如“Bug Report”。description 会作为卡片副标题出现建议写清楚“这个模板用来干什么”避免用户拿 Bug 模板提交功能需求。title 用来预填 Issue 标题我习惯写成[Bug]:让所有 Bug Issue 标题天然带统一前缀。labels 和 assignees 是自动化信息分别指定这个模板创建出来的 Issue 默认贴上哪些标签、指派给谁它们都可以是单个字符串或数组。body 是整个 YAML 文件的核心。它是一个列表每一项代表表单里的一块内容。GitHub 支持五种 typemarkdown、input、textarea、dropdown、checkboxes。具体能力对比如下type渲染效果常用属性是否支持 requiredmarkdown普通提示文本value否input单行文本框label、description、placeholder、value是textarea多行文本框label、description、placeholder、value是dropdown下拉菜单label、description、options、multiple是checkboxes复选框组合label、description、options选项级支持markdown 类型里你可以在 value 中写多行文本注意用 YAML 的块标量|来保留换行。input 适合短字段比如版本号、操作系统textarea 适合复现步骤、完整报错这类长内容dropdown 的 options 必须是数组给用户几个明确选项别让他们自由发挥。checkboxes 的 required 不在 validations 里控制而是在每个选项内部写 required: true。这个特别容易搞混很多人下意识在 checkboxes 上加 validations: required: true结果发现不生效。3.3 可以直接抄的 bug_report.yml 完整示例下面是我的一个实际项目在用的精简版字段、顺序、提示语都调过你可以直接复制再把 assignees 换成自己的账号。name: Bug Report description: 提交一段能稳定复现的 Bug 描述帮助维护者快速定位问题 title: [Bug]: labels: - bug - needs-triage assignees: - your-github-username body: - type: markdown attributes: value: | 感谢你花时间提交 Bug。带 * 的字段必填信息越完整定位越快。 - type: textarea id: bug-description attributes: label: 问题描述 description: 发生了什么实际结果和预期结果分别是什么 placeholder: | 例如点击登录按钮后页面白屏预期应跳转到控制台。 validations: required: true - type: textarea id: repro-steps attributes: label: 复现步骤 description: 尽量一步一步写清楚即使你觉得“太基础”。 placeholder: | 1. 访问项目首页 2. 点击登录按钮 3. 观察页面白屏 validations: required: true - type: input id: project-version attributes: label: 项目版本 description: 你正在使用的版本号可在项目配置文件中查看 placeholder: v1.2.3 validations: required: true - type: input id: environment attributes: label: 运行环境 description: 操作系统、浏览器或运行时版本 placeholder: macOS 14.2 / Chrome 121 / Node 20 validations: required: true - type: dropdown id: impact attributes: label: 影响范围 description: 这个问题影响到了哪些用户 options: - 只有我 - 部分用户 - 所有用户 validations: required: true - type: checkboxes id: confirmation attributes: label: 提交前确认 description: 逐项确认减少维护者来回追问 options: - label: 我已经确认这不是重复的 Issue required: true - label: 我能提供必要的日志或截图 required: false这个模板的设计思路是问题描述和复现步骤必填版本和环境影响必填影响范围用下拉控制让用户从三个选项里选避免写一堆“我觉得影响很大”之类的主观描述。提交前确认清单会在最后给用户一个“冷静检查”的机会这比强制他在正文里写“我已经查过重复”有用得多。3.4 给表单加自动化联动labels、assignees 的玩法很多维护者把 label 当成事后分类工具其实模板阶段就可以把 label 分好。比如 bug_report.yml 的 labels 里放了“bug”和“needs-triage”那么用户提交出来的 Issue 天然带着“待初审”标记。此时你的 GitHub Actions 工作流可以直接监听这个 label 做自动分流比如 bug needs-triage 的 Issue 自动进入某个项目面板feature_request.yml 的 labels 则放进另一个项目轨道。assignees 也是同理。小团队可以指定固定的人接收 Bug Issue哪怕后面再改派也比一个谁都不知道该谁处理的裸 Issue 强。不过要注意assignees 字段是静态的你没法根据表单里某个选项动态指派人。真要做“用户选了模块 A 就 模块 A 维护者”这种效果还是得靠 Actions 脚本去解析 Issue 正文模板负责把数据结构化地提供出来这一步就顺理成章了。4. config.yml 的作用空白 Issue 和联系入口怎么管模板文件负责“提什么”config.yml 负责“哪些能提、提不了时去哪”。它也是一个 YAML 文件放在同一个目录下文件名叫 config.yml。这里的 config.yml 不是数据库中间件那个 config不要看到同名文件就条件反射。4.1 文件位置与基本结构config.yml 的完整路径是 .github/ISSUE_TEMPLATE/config.yml。它的顶层字段只有两个blank_issues_enabled 和 contact_links。一个最基础的写法是blank_issues_enabled: false contact_links: - name: 项目官方文档 url: https://docs.example.com about: 提交 Issue 前请先查阅文档常见问题页面可能已有答案 - name: 社区讨论区 url: https://github.com/你的账号/你的仓库/discussions about: 功能建议、使用疑问、非 Bug 类讨论请前往 Discussions如果你没有创建 config.ymlGitHub 默认允许用户创建空白 Issue也不会显示任何额外联系入口。也就是说Config 文件的本质作用是对“新建 Issue 页面”做定制。4.2 blank_issues_enabled到底该不该留空白入口blank_issues_enabled 设置为 false 后新建 Issue 页面将不再出现“Open a blank issue”入口用户只能从你提供的模板里选。听起来很美好好像能把用户都框进模板。但我踩过一次坑过早关闭空白入口会让一小部分用户因为找不到“不适用任何模板”的选项而产生抵触最后避开你的仓库或者跑到 Discussions 里骂骂咧咧。对刚起步、模板数量还不够丰富的仓库我不建议关当你有至少三四个分类明确、覆盖大部分场景的模板时再考虑关掉也不迟。还有一种思路是保留空白入口但在 config.yml 里把 contact_links 的文档和讨论区做足。这样“用户感觉有地方可去”而不是被逼着乱选模板。实际上大型开源项目也未必关掉空白入口有些仓库就是靠模板做引导同时留一个“其他问题”的空白通道给边缘情况兜底。4.3 contact_links把非 Bug 流量导到该去的地方contact_links 的价值常常被低估。它不参与表单渲染而是显示在新建 Issue 页面下方的“联系链接”区域。比如你的项目有官方文档站有 GitHub Discussions 板块有即时沟通群都可以通过 contact_links 列出来。用户进来第一眼看到模板往下滚看到“如果你只是想问怎么用请看文档”提非 Bug 类 Issue 的概率就会小很多。注意给每个链接写清楚 about 字段它决定链接在页面上显示成什么说明文字。url 必须是可访问的完整地址GitHub 不会帮你校验写错了页面就会挂一个无效链接反而减分。另外contact_links 的 name 不要起得太大比如“帮助中心”这种如果链接背后只是 README 的一句话用户点进去会觉得被戏弄。5. 从零到上线创建、校验、实测一次走通配置模板最怕的是“写的时候很爽提交后没反应”。所以完整流程走一遍把每一步的关键点钉死你也就能少折腾几轮。5.1 通过网页或命令行创建文件最快速的方式是直接在仓库页面点“Add file → Create new file”。路径栏输入.github/ISSUE_TEMPLATE/bug_report.ymlGitHub 会自动创建中间目录。然后粘贴我上面给的 YAML 内容点提交。首次提交可以直接推到主分支模板是即时生效的不像 CI 配置要等工作流跑完。如果你习惯命令行也可以在本地仓库里先建好文件再 push。示例mkdir -p .github/ISSUE_TEMPLATE touch .github/ISSUE_TEMPLATE/bug_report.yml # 编辑文件内容 git add .github/ISSUE_TEMPLATE/ git commit -m docs: add bug report issue form git push origin main无论哪种方式提交后建议立刻去仓库主页看一眼新建 Issue 页面先确认模板卡片出现再点进去看表单渲染。5.2 提交前用 YAML 校验器自检YAML 是个看着简单、实际很娇气的格式。缩进不一致、Tab 和空格混用、特殊符号没加引号都能让文件解析失败。GitHub 不会在你提交的时候弹一个明确报错它只会悄悄让表单不可用非常阴险。我自己的做法是提交前用 Python 快速校验一下。如果你本地有 Python可以跑python -c import yaml,sys; yaml.safe_load(open(bug_report.yml)); print(YAML parse ok)如果没有安装 pyyaml先pip install pyyaml。或者用编辑器里的 YAML 插件保存时会顺手高亮语法错误。校验通过只是第一步字段语义对不对还得靠实测。5.3 实测在仓库中真实走一遍提交流程配置完模板后我强烈建议你自己以普通用户的身份提一条测试 Bug。操作路径是点仓库的 Issues → New issue → 选择 Bug Report 卡片 → 填表单 → 点击提交。此时重点关注几件事第一必填项是否真的拦人。把所有字段都留空直接提交正常情况是 GitHub 会提示校验失败。第二placeholder 和 description 是否足够友好你站在用户视角读一遍看有没有看不懂的术语。第三labels 和 assignees 是否自动挂上创建出来的 Issue 侧边栏应显示 front matter 里写好的标签和指派人。都通过之后把这条测试 Issue 直接关闭并删除避免污染列表。如果你不想在正式仓库折腾可以建一个专用来测试的私有仓库比如 test-issue-templates把同样的文件传上去点一遍。模板的生效机制与仓库大小无关私有仓库也能完整验证。实测下来最稳的流程就是先在本地校验 YAML再推到测试仓库确认渲染最后复制到正式仓库。5.4 后续维护模板版本化与迭代节奏模板不是写完就完事的东西。我发现很多仓库的模板三年不更新里面的链接早就失效字段和产品现状也对不上。维护模板的节奏可以跟随版本迭代每次发版调整表单字段时顺手检查模板里的选项是否还准确新增了模块或功能入口就在 dropdown 的 options 里加一项。模板文件本身有 git 历史这给了你天然的版本管理能力。改错了随时能回滚。我建议把模板变更和文档变更放到同一个 commit 里比如这次改了 Bug 模板里的“影响范围”选项提交信息写成“docs: update bug form impact options”将来查起来很清楚。6. 常见问题与排查技巧实录这一节汇总我实际遇到过的坑全部来自真实仓库操作不掺水。6.1 模板提交了表单却一直不出现先检查目录名大小写。ISSUE_TEMPLATE全大写config.yml全小写。再检查文件后缀名.yml不是.yaml的问题不大但如果你写成了bug_report.yml.txtGitHub 完全不认。然后看仓库的 Issues 功能是否被关闭Settings → General → Features → Issues 必须处于开启状态否则模板页面都进不去。最后强制刷新浏览器缓存有时候接口数据没更新你看到的是旧页面。文件放在 .github/ISSUE_TEMPLATE 下如果目录里没有任何模板config.yml 单独存在也是可以的但新建 Issue 页面就不会有模板卡片只显示 config 配置。一般没人这么干提一下避免误解。6.2 表单能显示但提交后内容错乱或字段缺失这类问题多数出在 YAML 的 value 和 placeholder 里。如果你在 value 中写了特殊字符比如以冒号、井号开头的内容YAML 解析时会当成注释或字典结构最好用双引号包起来或者改用|块标量保留原文。比如 placeholder 的字符串里带了:就会让解析直接崩掉。还有一个容易被忽略的地方body 数组里每个元素如果写了重复的 idGitHub 会展示两个同名字段提交时互相覆盖。给每个块一个唯一 id像我在模板示例里那样用 bug-description、repro-steps就不会撞车。6.3 下拉选项、复选项和必填规则失效这通常是语法位置写错了。dropdown 的必填是 validations.requiredcheckboxes 的必填是 options 内部每个选项的 requiredinput 和 textarea 的必填也是 validations.required。一定不要跨类型乱套。另外 dropdown 的 options 不能为空数组至少要给一个选项不然表单没办法渲染。复选项如果想让用户“至少勾选两项”GitHub 原生的 checkboxes 并不支持自定义数量限制只能通过每个选项的 required 做“必须勾这个”级别的控制更复杂的校验需要后续 Actions 处理。还有一点不要把 dropdown 的 options 写得太多超过十项用户在手机上就划得很痛苦。能用五个选项解决的问题别列二十个。6.4 多个模板同时存在时的排序与去重当目录里有多个模板文件GitHub 会按某种顺序把它们列出来通常接近文件名排序。如果你在意顺序可以用数字前缀控制比如01_bug_report.yml、02_feature_request.yml。同时要注意模板之间的边界别让“Bug Report”和“问题反馈”同时存在用户根本分不清。我见过仓库里放了四个模板描述都是“有问题反馈”最后用户随便点一个填维护者还得手动转。模板之间既要有分工又要在 description 里说清边界。比如 bug_report 说“软件表现不符合预期需要修复”feature_request 说“希望增加能力或改进体验”这两句话就能让大多数用户做出正确选择。6.5 多语言仓库与周边工具配合如果你的仓库用多种语言维护比如 README 是英文但用户群里主要是中文使用者我建议建两个模板比如bug_report_en.yml和bug_report_zh.ymlname 和 description 分别用英文和中文写清楚。新建 Issue 页面会同时出现两张卡片用户自然选择看得懂的那个。注意同一个仓库里不要给中文模板挂和英文模板一模一样的 label至少要在 label 上区分语言或渠道否则统计时还得靠正文猜。另外模板配置可以和 PR 模板、贡献指南配合起来。我的仓库里Issue 模板负责接收问题PR 模板负责接收代码CONTRIBUTING.md 里写清楚“提 Issue 前先搜索、按模板填、附上版本信息”三层一起作用仓库才真正像个正规军。这些都没什么高深原理关键是想清楚每个入口承担什么职责用户就不会走错门。最后留一个我自己常用的判断标准当你打开仓库的 Issue 列表不需要点进正文就能从标题和标签上知道这条 Issue 是干什么的、严重程度如何、涉及哪个模块说明模板体系已经合格了。模板不是越多越好覆盖住主要场景、让数据入口整洁比一个月内堆出十个表单文件有意义得多。
