HTML工程化核心在于语义明确与可验证性：doctype必须首行、属性小写、class值禁空格、资源分src/public、BEM规范隔离语义层级、data-承载逻辑、语义标签严格按W3C角色使用。
HTML 工程化不是加一堆工具链，而是让每个 <header>、class 和 <meta charset="UTF-8"> 都有明确意图和可验证依据。
为什么 HTMLHint 比手写 checklist 更可靠
人工检查容易漏掉隐性错误：比如 <img src=logo.png> 缺引号，浏览器能渲染但会截断空格后的属性；又如 <input required> 在某些 SSR 场景下被解析为未启用状态。HTMLHint 的规则是静态分析，不依赖运行时环境。
-
doctype-first规则强制<!DOCTYPE html>必须出现在第一行，避免怪异模式（Quirks Mode）触发布局错乱 -
attr-lowercase拦截CLASS="nav"这类写法，防止与 JS 中element.className行为不一致 -
id-class-value禁止class="user profile"这种含空格的值——它实际会被拆成两个 class，但开发者常误以为是一个 - VS Code 中启用后，保存即报错，比“等测试提 bug 再改”快 3 个迭代周期
src/ 里放什么，public/ 里放什么，别凭感觉
混淆静态资源和模板逻辑，是后期维护成本飙升的起点。关键区分点在于：是否参与构建流程、是否会被 Webpack/Vite 处理。
-
public/只放真正“原样复制”的文件：favicon.ico、robots.txt、index.html（仅作为入口模板，不含动态数据） -
src/index.html不该存在——它应由构建工具生成，或从public/index.html注入变量（如%VITE_APP_TITLE%） -
src/assets/下的logo.svg可被import logo from '@/assets/logo.svg'引用，支持按需压缩、hash 命名、tree-shaking -
src/components/里禁止直接写<img src="/logo.png">——路径应相对或通过 import，否则构建后 404
class 命名不是风格问题，是接口契约
当一个 class="card" 被 12 个组件复用，而某天你改了它的 padding，就有 12 处视觉意外。BEM 不是教条，是把隐式依赖显性化。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
-
card是 Block，card__header是 Element，card--featured是 Modifier——三者语义隔离，改card__header不影响其他部分 - 禁止在 class 中塞样式描述：
red-text、float-left、mt-4（除非你明确采用 Utility-First 方案并全局约束） - JS 绑定时优先用
data-属性：data-action="submit"，而非靠class="btn-primary"判断行为——class 应只管呈现，不承载逻辑 - 团队内统一前缀（如
u-*表示 utility，js-*表示 JS 钩子），避免btn和button同时存在
语义标签失效的三个典型场景
<main> 和 <section> 不是“写了就赢”，它们在 DOM 树中承担真实角色，错误使用反而破坏可访问性。
- 页面有多个
<main>：违反 W3C 规范，屏幕阅读器只会朗读第一个，其余内容被跳过 -
<nav>包裹搜索框或登录入口：导航应只含站点级跳转链接，搜索属于交互控件，用<form>+role="search"更准确 -
<article>套<div class="ad-banner">：广告不是独立内容，强行套语义标签会让辅助技术误判内容重要性 - 检查方法很简单：Chrome DevTools → “Accessibility” 面板 → 查看 “Landmark” 结构是否合理
工程化的复杂点不在工具配置，而在每次写 <div> 前多问一句：这个容器有没有不可替代的语义？它的 class 名能不能让三个月后的自己一眼看懂用途？
