.github文件夹是 GitHub 平台用于 标准化项目管理、协作流程和社区治理 的核心配置文件夹。以下是其功能和作用，以及附件中列出的每个文件/文件夹的详细说明：
文件/文件夹的作用
| 文件名 | 作用 |
|---|---|
ISSUE_TEMPLATE | Issue 模板目录：包含标准化模板（如 Bug 报告、功能请求），强制用户在提交 Issue 时填写必要信息（如复现步骤、版本号）。 |
CODE_OF_CONDUCT.md | 行为准则：规定社区成员互动规则（如禁止歧视、骚扰），违反者可能被禁言或封禁。 |
COMMIT_CONVENTION.md | 提交信息规范：约定 Git 提交信息的格式（如 feat:, fix:），便于生成 CHANGELOG 和代码审查。 |
CONTRIBUTING.md | 贡献指南：说明如何参与贡献（如开发环境配置、测试流程、Issue/PR 规范）。 |
FUNDING.yml | 赞助配置：定义项目赞助渠道（如 GitHub Sponsors、Open Collective），引导用户支持项目发展。 |
PULL_REQUEST_TEMPLATE.md | PR 模板：规范 Pull Request 的提交内容（如关联 Issue、修改描述、测试覆盖）。 |
与其他目录的关系
/.github/workflows（未列出但常见）：存放 GitHub Actions 自动化脚本（如 CI/CD 流程）。/docs：项目文档，与CONTRIBUTING.md互补（前者面向用户，后者面向开发者）。
ISSUE_TEMPLATE/config.yml
核心配置解析
1. blank_issues_enabled: false
- 作用：禁止用户提交空白 Issue（即不通过模板直接创建 Issue）。
- 意义：强制开发者使用标准化模板（如 Bug 报告、功能请求），确保问题描述完整，减少低质量 Issue。
2. contact_links
-
作用：在 Issue 创建页面显示自定义联系链接，引导用户到指定渠道。
-
包含的链接：
链接名称 URL 用途 Create new issue https://new-issue.vuejs.org/跳转到 Vue 官方 Issue 向导页面（强制标准化提交）。 Patreon https://www.patreon.com/evanyou引导用户通过 Patreon 赞助 Vue.js 开发（个人支持渠道）。 Open Collective https://opencollective.com/vuejs引导用户通过 Open Collective 赞助（开源集体赞助渠道）。
文件的作用
-
规范化 Issue 提交
- 通过禁用空白 Issue 和跳转至
new-issue.vuejs.org，确保所有问题都按模板填写（如复现步骤、版本信息等）。
- 通过禁用空白 Issue 和跳转至
-
分流非技术请求
- 将赞助请求引导至 Patreon/Open Collective，避免 GitHub Issues 被无关内容占用。
-
维护开源可持续性
- 明确展示赞助渠道，鼓励社区资助项目发展。
与其他文件的关系
-
与
ISSUE_TEMPLATE/目录下的模板文件（如bug_report.md）配合使用：config.yml控制是否强制使用模板，而模板文件定义具体内容格式。
-
与
CONTRIBUTING.md：- 共同构成贡献指南，前者侧重 Issue 提交流程，后者涵盖更广泛的协作规范。
用户可见效果
当用户在仓库点击 "New Issue" 按钮时，会看到以下界面（而非直接创建空白 Issue）：
- 显眼的提示： “Don’t see your issue here? Use the link below.”
- 跳转链接按钮（指向
new-issue.vuejs.org）。 - 底部的赞助联系方式（Patreon 和 Open Collective）。
适用场景
- 提交 Bug/功能请求：必须通过官方向导页面。
- 支持项目：点击赞助链接而非创建无关 Issue。
- 维护者管理：减少无效 Issue，聚焦核心问题。
PULL_REQUEST_TEMPLATE.md文件
核心作用
-
标准化 PR 提交
- 强制要求开发者按模板填写关键信息，避免遗漏重要内容（如关联 Issue、测试覆盖）。
-
提高审查效率
- 通过分类选项（如 Bugfix、Feature）快速判断 PR 性质，减少沟通成本。
-
保障代码质量
- 明确要求测试通过、分支规范等，确保合并的代码符合项目标准。
模板内容解析
1. PR 类型分类（必选）
What kind of change does this PR introduce? (check at least one)
- [ ] Bugfix
- [ ] Feature
- [ ] Code style update
- [ ] Refactor
- [ ] Build-related changes
- [ ] Other, please describe:
- 作用：明确 PR 的修改性质，便于分类管理（如生成 CHANGELOG 时区分功能新增和 Bug 修复）。
2. 破坏性变更声明（必选）
Does this PR introduce a breaking change? (check one)
- [ ] Yes
- [ ] No
- 若选 "Yes" ：需补充说明影响范围和迁移方案，例如：
## Impact
- 移除
v-bind.sync，改用v-model。 ## Migration - 用户需将<Child :foo.sync="bar" />改为<Child v-model:foo="bar" />。
3. 基础要求验证（必填）
The PR fulfills these requirements:
- [ ] It's submitted to the `dev` branch for v2.x (or to a previous version branch), not the `master` branch
- [ ] When resolving a specific issue, it's referenced in the PR's title (e.g. `fix #xxx[,#xxx]`, where "xxx" is the issue number)
- [ ] All tests are passing: [Development Setup](https://github.com/vuejs/vue/blob/dev/.github/CONTRIBUTING.md#development-setup)
- [ ] New/updated tests are included
-
关键规则：
- 分支规范：Vue 2.x 的 PR 必须提交到
dev分支（非master）。 - Issue 关联：PR 标题需包含关联的 Issue 编号（如
fix #123）。 - 测试覆盖：必须通过全部测试，新增代码需补充测试用例。
- 分支规范：Vue 2.x 的 PR 必须提交到
4. 新功能说明（可选）
If adding a new feature, the PR's description includes:
- [ ] A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)
- 作用：防止开发者盲目开发未共识的功能，要求先通过 Issue 讨论可行性。
5. 其他信息
Other information:
- 可补充代码设计思路、依赖变更、兼容性考虑等。
实际应用示例
- 示例 PR 标题：
fix(compiler): handle v-for key warning with fragment nodes close #4567
- 示例 PR 内容：
## Change Type
- [x] Bugfix
## Breaking Change
- [ ] Yes
- [x] No
## Requirements
- [x] Submitted to `dev` branch
- [x] Fixes #4567
- [x] All tests passed
- [x] Added test cases for fragment key checks
## Description
修复当 `v-for` 用于 `<template v-for>` 时，键（key）警告误报的问题。
