根本原因是开发、测试、设计三方对“HTML质量”定义不同：开发重功能实现，测试重结构稳定性，设计重语义准确性；若仅靠口头约定，必在class命名、data-*属性、标签嵌套上产生分歧。
为什么测试环境里HTML结构总和开发不一致？
根本原因不是测试没看代码，而是开发、测试、设计三方对“HTML质量”的定义不同：开发关注功能实现，测试关注可自动化识别的结构稳定性，设计关注语义是否准确传达意图。三者若只靠口头约定，必然在 class 命名、data-* 属性使用、标签嵌套深度上产生分歧。
实操建议：
- 把 HTML 质量拆解为三个可验证维度：语义正确性（是否用
<nav></nav>而非<div class="nav">）、结构稳定性（<code>id和data-testid是否唯一且不变）、可访问性基础（alt、lang、aria-label是否存在） - 测试团队在编写 E2E 用例时，必须基于
data-testid定位，禁止依赖class名或视觉文本——否则开发一改样式就全挂 - 设计交付物中需明确标注关键语义区域，例如“此处必须为
<main></main>，不可用<section></section>替代”，而非只说“主内容区” - 项目根目录必须有
.prettierrc，且明确写死："tabWidth": 2、"useTabs": false、"htmlWhitespaceSensitivity": "strict" - VS Code 的
settings.json中强制指定默认格式化工具："html.format.defaultFormatter": "esbenp.prettier-vscode"，禁用内置 HTML 格式器 - 测试和设计人员哪怕不写代码，也应安装 Prettier 插件并启用
editor.formatOnSave——他们改文案、调结构时，也能自动对齐 - 所有交互元素必须带
data-testid，且命名与设计文档中的组件名一致，例如data-testid="header-search-bar" - 语义关键节点（如主内容、页脚导航）用标准语义标签 +
role双保险，例如<main role="main"></main>，避免仅靠 CSS 类名判断 - 测试用例中禁止出现
getByTestId('button-123')这类无意义 ID，必须是getByTestId('primary-cta-button')——名字本身即文档 - 用
prettier --check检查格式，失败则阻断构建——不是警告，是报错 - 用
html-validate检查语义合规性，重点校验：doctype是否存在、lang属性是否设置、img是否缺失alt、button是否有可访问文本 - 禁止在 CI 中运行
prettier --write自动修复——修复必须由人确认，否则会掩盖结构性误用（比如把<div> 错误替换成 <code><article></article>）真正难的不是写规则，是让设计提需求时就带语义约束，让测试写用例时就绑定结构标识，让开发提交前就跑通三道校验。一旦某环节跳过，对齐就从根上断了。
VS Code + Prettier 如何让三方看到同一份缩进？
编辑器配置不统一，是三方协作中最隐蔽的格式污染源。有人用 Tab 缩进，有人用 4 空格，有人开 html.format.indentInnerHtml，有人关——结果 Git diff 里全是空格变更，掩盖真实逻辑修改。
实操建议：
怎么让测试脚本能“读懂”设计意图？
测试脚本常因 DOM 结构微调而失败，表面是 selector 不稳定，深层是设计、开发、测试未共享同一套“结构契约”。比如设计要求“搜索框必须可被屏幕阅读器识别为搜索区域”，但开发只加了 class="search-input"，测试却用 document.querySelector('.search-input') 断言——这既没满足无障碍，也不抗重构。
实操建议：
CI 流程里该检查哪些 HTML 质量硬指标？
本地格式化再好，也挡不住有人绕过 pre-commit 直接 push。CI 阶段必须卡住几条不可妥协的线，否则“三方对齐”就是空谈。
实操建议：
