贡献 Bootstrap 官方项目（twbs/bootstrap）必须修改 LESS/JS 源码并走构建流程，不可直接改 dist 文件；PR 需语义化分支、Conventional Commits 提交信息、完整文档与向后兼容处理。
直接参与 Bootstrap 官方项目（twbs/bootstrap）的贡献，不是改你本地的 CSS 或 JS 文件就能提交 PR 的——绝大多数改动必须源自上游 LESS 源码，经由自动化转换流程生成。跳过这一步，你的 PR 几乎肯定被拒。
先确认你要改的是哪个 Bootstrap 项目
“Bootstrap”这个名字下实际有多个独立维护的生态项目，贡献路径完全不同：
-
twbs/bootstrap（官方 Bootstrap）：核心框架，LESS 源码，所有资产（CSS/JS/fonts）是构建产物； -
bootstrap-sass：第三方 Sass 移植版，但它的 SCSS 不是手写的，而是靠convertrake 任务从twbs/bootstrap自动转换来的； -
bootstrap-vue、bootstrap-form、bootstrap-slider等：各自独立的封装库，有自己的源码结构、测试和发布流程； -
Bootstrap 5.3 文档（site/content/docs/5.3/）：Hugo 驱动，翻译或文档改进走纯 Markdown 提交。
搞错项目仓库，等于往错邮箱发简历。
改官方 Bootstrap（twbs/bootstrap）：LESS 是唯一源码
你不能直接编辑 dist/css/bootstrap.css 或 scss/_variables.scss 并提 PR——这些文件是生成的，会被 CI 覆盖。正确路径是：
- 所有样式修改必须在
scss/目录下的 LESS 文件中进行（如less/variables.less、less/mixins.less）； - JS 行为修改必须在
js/src/的 ES6 源码里，构建后生成dist/js/bootstrap.js； - 运行
npm run css或npm run js验证构建是否通过； - 必须补全对应单元测试（
js/tests/unit/），尤其是涉及公共 API 变更时； - 如果改的是组件行为（比如
modal的 backdrop 关闭逻辑），需在js/tests/browser/下加截图回归测试。
提 PR 前必须绕不开的三件事
维护者每天看几十个 PR，跳过以下任一环节，基本秒关：
-
git checkout -b fix/modal-backdrop-click：分支名要语义化，不接受patch-1或my-fix； - 提交信息用 Conventional Commits 格式，例如：
fix(modal): prevent backdrop click from closing when data-bs-backdrop="static"； - 在 PR 描述里明确写清：
Fixes #XXXX（关联 issue）、复现步骤、截图/GIF（如果是 UI 变更）、是否影响 SSR 或可访问性。
没有关联 issue 的功能类 PR，大概率被要求先开 issue 讨论设计合理性。
最容易被忽略的细节：文档与向后兼容
哪怕只改了一行 JS，只要它暴露了新选项、修改了默认值、或删了某个方法，就必须同步更新三处：
-
site/content/docs/5.3/components/modal.md（组件文档）； -
site/content/docs/5.3/getting-started/javascript.md（JS 全局配置说明）； -
js/src/modal.js里的 JSDoc 注释（影响 IDE 提示和生成 API 文档）。
另外，Bootstrap 对 break change 极其敏感——删除一个 class、重命名一个 data 属性、改变事件触发时机，都得加 deprecated 警告并保留旧逻辑至少一个大版本。想“清理技术债”？先写 migration guide。
