多仓库中html规范统一落地需封装为可复用npm包（如@org/html-lint-config），含htmlhint.json、eslint.config.js等，并通过extends继承；禁用git子模块，因其更新繁琐、路径硬编码、不支持语义化版本；ci中显式执行lint:html脚本并覆盖public目录，规则变更须经pr审批与跨团队合议。
多仓库中 HTML 规范怎么统一落地？
HTML 本身不带规范执行能力，所谓“HTML 代码质量规范”，实际是指对 HTML 文件的结构、语义、属性使用、可访问性（a11y）、内联脚本/样式约束等的检查规则。在 multi-repo 架构下，这些规则容易散落在各仓库的 .htmlhintrc、eslint-plugin-html 配置、CI 脚本或 README 里，导致检查不一致、升级不同步、新人踩坑。
真正可行的做法是：把 HTML 规范抽象成可复用的配置包，而非文档或脚本片段。比如封装为一个 npm 包 @org/html-lint-config，内部包含：
-
htmlhint.json（含attr-lowercase、id-unique、img-alt-require等强制项） -
eslint.config.js（启用eslint-plugin-html并指定规则） -
package.json的peerDependencies声明所需工具版本
各业务仓库只需 npm install --save-dev @org/html-lint-config，并在各自 .eslintrc.cjs 中 extends: ['@org/html-lint-config'] 即可。版本升级时，统一发版 + 依赖更新，避免手动复制粘贴配置。
为什么不能直接用 Git 子模块同步 HTML 检查配置？
子模块看似能“共享配置”，但实际在 multi-repo 场景下会引入三类硬伤：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 每个仓库需手动
git submodule update --remote才能拉到最新配置，CI 流水线容易漏掉这步，导致某几个仓库长期跑旧规则 - 子模块路径固定（如
.config/html-rules/），但不同仓库的 lint 工具加载路径不一致（ESLint 用extends，HTMLHint 用--config），硬编码路径易出错 - 子模块 commit hash 锁死，无法享受 semver 自动升级（比如
^1.2.0），每次更新都要人工进每个仓库改 hash
相比之下，npm 包天然支持版本范围、CI 缓存友好、工具链兼容性强。只要团队有统一的私有 registry（如 Verdaccio 或 Nexus），发布和消费成本极低。
CI 中如何确保 HTML 规范被真实执行？
很多团队只在本地装了 lint 工具，但 CI 脚本里没跑，或者只跑 JS 不跑 HTML。关键点在于：把 HTML 检查显式写进 package.json 的 scripts，并强制纳入 CI。
- 在共享配置包中提供标准 script：
"lint:html": "htmlhint \"**/*.html\" --config node_modules/@org/html-lint-config/htmlhint.json" - 各仓库的
package.json统一加："lint": "npm run lint:js && npm run lint:html" - CI 的
.gitlab-ci.yml或.github/workflows/ci.yml必须调用npm run lint，且设置fail-fast: true
特别注意：某些框架（如 Next.js）默认忽略 public/ 下的 HTML，需在 htmlhint 配置中显式加入 "files": ["**/*.html", "public/**/*.html"]，否则静态页规范形同虚设。
多人协作时 HTML 规范冲突怎么处理？
最常见的冲突不是代码，而是规则解释权。比如某团队认为 <div role="button"> 可接受，另一团队坚持必须用 <code><button></button>。这类问题不能靠工具解决，得靠机制：
- 所有规则变更必须提 PR 到
@org/html-lint-config仓库，并附带可复现的 HTML 片段和 WCAG 条款依据 - PR 需至少 2 名跨团队成员 approve，其中 1 名必须来自 a11y 专项小组（如有）或前端架构组
- 禁用
// htmlhint-disable这类行级关闭——它会绕过 CI 检查，且难以审计；确需例外，必须走exceptions.json统一管理，并记录原因和有效期
真正难的从来不是“怎么配工具”，而是让分散在不同仓库的开发者，对同一份 HTML 规则有相同理解、相同敬畏。配置可以同步，认知偏差却需要持续对齐。
