微型交付团队需用最低成本守住HTML质量三道底线：能跑、能读、能改；通过严格htmlhint配置、Console报错拦截、语义标签规范及ID变更同步grep，嵌入开发动线实现高效质量卡点。
微型交付团队没资源堆工具链、没人力搞专职QA，但线上HTML模板一崩就是整页不可用——这种场景下，“质量卡点”不是加流程，而是把检查动作嵌进开发者自然动线里，用最低成本守住三道底线：能跑、能读、能改。
htmlhint 配置必须关掉“宽松模式”
很多团队装了 htmlhint 却形同虚设，原因就一条：.htmlhintrc 里开着 "attr-lowercase": false 或 "tag-self-close": false 这类放行项。这不是容错，是主动埋雷。
- 所有属性名强制小写（
class不是CLASS），否则某些 SSR 框架会静默忽略 -
img、br、input必须自闭合，不写</img>—— 浏览器解析行为在不同 HTML mode 下不一致 - 禁用
"attr-no-duplication"的宽容配置，重复id或class是后期 JS 操作失败的高频根因
建议直接用社区维护的轻量规则集：htmlhint --config node_modules/htmlhint-config-strict/.htmlhintrc，别自己从零配。
DevTools Console 报错要当编译错误拦住
微型团队没有专职测试盯控制台，那就让这个动作变成提交前必检项：每次改完 HTML，手动刷新页面，盯着 Console 看有没有 ReferenceError 或 TypeError: Cannot read property 'xxx' of null。
立即学习“前端免费学习笔记（深入）”；
- 这类错误 90% 来自 JS 脚本提前执行，比如
<script>document.getElementById('main')</script>放在<body>开头，但#main在后面 - 解决方案不是加
defer，而是统一约定：所有内联脚本必须包裹在<script>document.addEventListener('DOMContentLoaded', () => { ... })</script> - 如果模板用于 SSR（如 Next.js），所有含
window或document的逻辑必须带运行时判断：if (typeof window !== 'undefined') { ... }
语义标签误用比缺失更危险
团队常以为“用了 section 就算语义化”，其实错用 section、article、aside 会破坏辅助技术识别逻辑，反而比全用 div 更难修复。
-
section不是“分块容器”，它必须有明确标题（<h2>级以上），否则应改用div -
article只用于可独立分发的内容（博客、新闻、评论），用户头像卡片、商品列表项不算 -
nav内必须是导航链接，如果塞了搜索框或 logo，得用<header>包一层再放nav - 检查方法极简：删掉所有 class 和 style，只留标签和文字，看结构是否还能被正常朗读或理解
真正卡住微型团队的，往往不是不会写语义标签，而是改一行 HTML 后，没人知道 JS 里哪三个地方硬编码了 getElementById('old-id') —— 所以每次新增/重命名 id，必须同步 grep 全项目 JS 文件，漏一次，上线就白屏。
