html本身不直接产生技术债务，但混杂逻辑、缺乏语义、忽略可访问性或硬编码样式会加速前端代码腐化，尤其与js/css耦合后重构成本远高于后端。
HTML 本身不直接产生技术债务，但混杂逻辑、缺乏语义、忽略可访问性或硬编码样式会让前端代码快速腐化——尤其当它和 JS/CSS 耦合后，重构成本远高于后端。
HTML 语义标签替换 div 块的判断标准
用 <section></section>、<article></article>、<nav></nav> 替换无意义的 <div class="wrapper"> 不是“为了语义而语义”。关键看是否满足以下任一条件：
<ul>
<li>该区域在页面中承担明确内容角色（如主导航、侧边栏、页脚）</li>
<li>屏幕阅读器需识别其功能（例如 <code><main></main> 是唯一主内容区）
反例：<div class="card"> 不需要改成 <code><article></article>，除非它确实封装独立、可分发的内容单元；强行替换反而模糊意图。
内联样式与 class 命名冲突的实际影响
style="margin-left: 20px" 看似快捷，但它会覆盖 CSS 文件中的响应式规则、主题切换逻辑，甚至让 !important 滥用成为必然。更隐蔽的问题是：
- 无法通过 JS 动态 toggle 样式状态（比如
classList.toggle("hidden")失效） - DevTools 中难以定位来源（内联样式权重最高，且无文件路径）
- 自动化工具（如 PurgeCSS）无法安全移除未使用的 class
实操建议：所有视觉表现必须走 class；仅允许 style="display: none" 用于 JS 临时隐藏（且应优先用 aria-hidden + class 控制）。
表单元素缺失 name 或 id 的连锁反应
一个没写 name 的 <input>，在提交时根本不会出现在 FormData 中——后端收不到字段，测试用例反复失败，但错误日志里只显示“参数为空”，排查耗时远超修复时间。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
更易被忽略的是 id 缺失对可访问性的破坏：
-
<label for="email"></label>指向不存在的id→ 点击 label 无法聚焦输入框 - 屏幕阅读器跳过该控件，用户无法通过语音指令操作
- Lighthouse 审计直接标红“Form elements do not have associated labels”
检查清单：<input> 必须同时有 name（提交用）和 id（关联 label 用）；<textarea></textarea> 同理；<select></select> 的每个 <option></option> 应有 value，而非依赖 innerText。
模板字符串拼接 HTML 的重构代价
JS 中用 `<div>${data.name}</div>` 渲染列表，短期快，长期痛。问题不在语法本身，而在它绕过了框架/编译器的校验能力：
- XSS 风险：未转义
data.name直接插入 → 可执行脚本 - 无法静态分析：工具无法检测拼错的属性名（如
clas="btn"） - 重构时难定位：搜索
<button> 找不到动态生成的按钮</button>
替代方案不是“禁止字符串拼接”，而是明确边界：
— 简单、静态、可信内容（如纯数字 ID）可用字符串插值
— 任何含用户输入、需交互、或未来可能复用的结构，必须走模板引擎（如 HTM、Lit）、框架组件或 DOM API（document.createElement + textContent）
