HTML 值得学，但应聚焦其作为浏览器协议的核心作用；手写 HTML 在语义、可访问性、SEO、表单状态保持、安全配置（如 iframe sandbox、CSP nonce）及跨平台约束（Electron、小程序、IoT）中不可替代，需深度理解其与渲染管线、安全策略和辅助技术的协同机制。
HTML 值得学，但不是作为一门“要啃透”的编程语言去学——它是你和浏览器之间最直接的协议，学它是为了让别的技术（比如 JavaScript、CSS、甚至 React 或小程序框架）能真正落地。
什么时候该写原生 HTML 而不是靠框架生成？
当你需要控制语义结构、可访问性（a11y）或 SEO 效果时，手写 HTML 不可替代。框架生成的 DOM 往往冗余、标签错用（比如用 div 冒充 button），导致屏幕阅读器误读、搜索引擎降权。
- 表单提交失败后保留用户输入，靠
value和checked属性原生行为，比 JS 手动同步更可靠 - 用
article、nav、main替代一堆div class="section"，对 Lighthouse 评分和 WCAG 检查有直接影响 - 嵌入第三方内容（如地图、支付弹窗）时，
iframe的sandbox和referrerpolicy必须手动写，框架通常不暴露这些细节
form 提交失败时，为什么页面刷新后数据全丢了？
因为没利用 HTML 原生表单的状态保持机制。现代前端常把表单完全交给 JS 控制，反而丢掉了浏览器内置的恢复能力。
- 确保
input有正确的name属性（不是id），否则提交时不会携带值 - 使用
required、type="email"等原生校验，失败时浏览器自动聚焦并提示，无需额外 JS - 服务端返回 422 错误时，用
server-side rendering重渲整个form并保留用户已填字段，比纯客户端状态管理更健壮
在 Electron / 小程序 / IoT 管理页里，HTML 的边界在哪？
它不再是“写完扔给浏览器就完事”的静态层，而是宿主环境的约束接口。
- Electron 中，
file://协议下默认禁用fetch，需手动配置webPreferences: { webSecurity: false }（但会牺牲安全性） - 微信小程序的
WXML不支持iframe、script标签，view对应div，但生命周期和事件模型完全不同 - IOT 管理页用
WebSocket接收设备 JSON 数据时，DOM 更新必须节流——频繁innerHTML = ...会导致重排卡顿，应批量操作或用DocumentFragment
CI/CD 流程里，HTML 文件最容易被忽略的检查项
它不像 JS 有 ESLint、CSS 有 Stylelint，HTML 的质量常靠人眼扫，但其实可以自动化。
立即学习“前端免费学习笔记（深入）”；
- 用
html-validate检查aria-*属性缺失、label未绑定for、tabindex乱序等可访问性硬伤 - Webpack 构建时通过
html-webpack-plugin注入nonce值，配合 CSP 头防 XSS，但若模板里写了内联onclick就直接失效 - Git 提交前跑
prettier --parser html统一格式，避免团队里有人用缩进、有人用空格，合并冲突时全是噪音
HTML，难点不在标签怎么拼，而在理解它如何与浏览器渲染管线、安全策略、辅助技术、构建流程咬合——这些地方，改一行属性可能影响加载性能，漏一个 alt 可能让整页被监管通报。 
