class和id命名必须语义化，即描述功能或内容而非样式、位置或标签类型，如用article-meta代替red-text，用main-content代替left-sidebar，并统一采用kebab-case，确保可维护性与团队协作效率。
class 和 id 命名必须语义化，不能描述样式或位置
直接写 class="red" 或 id="left-sidebar" 是最常见也最危险的起点。这类命名在第一次改版时就失效：颜色变橙、侧边栏移到右边，HTML 里却还留着过期标签。更麻烦的是，它会让 CSS 和 JS 的维护变成猜谜游戏——没人知道 class="clear" 到底是清浮动、清缓存，还是清 localStorage。
实操建议：
- 用功能或内容角色命名：
class="article-meta"、class="search-input"、id="main-content" - 避免纯样式词：
red、float-left、big-text—— 这些应交给 CSS 变量或 utility class（如u-text-red）处理 - 禁用标签名嵌入：
div-header、p-intro会锁死元素类型，换section或span就得同步改 class
BEM 命名不是加双下划线就行，关键在组件边界是否真实存在
class="card__title--large" 看似标准，但如果 card__title 在 footer、modal、sidebar 里被复用，它就不是 card 的子 element，而是独立 block —— 此时该叫 heading-primary 或 title-section。BEM 失效的根源，常是把 DOM 结构当成了组件结构。
实操建议：
- 每个
__必须对应一个真实、不可拆分的父子关系：按钮内部图标只服务于该按钮，才可叫btn__icon - 禁止嵌套 element：
card__content__title是错的；正确是card__content+card__title（同级）或单独的headingblock - modifier（
--）只修饰外观或状态，不改布局逻辑：btn--disabled✅，btn--full-width❌（这属于容器职责）
文件名、data-* 属性、form name 都要统一用 kebab-case
服务器和 URL 对大小写、下划线极其敏感。GitHub Pages 上 user_profile.html 可能返回 404；data-userid="123" 在 Alpine.js 里无法被 x-bind:data-userid 正确识别；而 <input name="userEmail"> 在 PHP 后端可能被解析为 $_POST['userEmail'] 或 $_POST['useremail']，取决于服务器配置。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
实操建议：
- HTML 文件名全小写 +
-分隔：product-list.html、faq-section.html，首页固定为index.html -
data-属性必须加项目前缀：data-shop-product-id，而非data-product-id（防第三方库冲突） - 表单
name和for/id必须严格一致且 kebab-case：<label for="user-email"></label>↔<input id="user-email" name="user-email">
id 不是“带样式的 class”，唯一性和稳定性比语义更重要
很多人用 id="btn-submit" 绑定 JS，结果页面里冒出第二个提交按钮，JS 只操作到第一个；或者 SSR 渲染时动态生成 id="item-{{id}}"，但后端没做去重，hydration 阶段 React 直接报 key 冲突。id 的本质是锚点与精确控制点，不是批量选择器。
实操建议：
- id 仅用于三类场景：跳转锚点（
id="contact"）、JS 单点操作（id="modal-confirmation"）、<label for></label>关联 - 含特殊字符的 id（如
user.email）必须在 JS 中转义：document.getElementById("user\.email")，否则被当 CSS 选择器解析 - 服务端渲染中，id 值必须全局唯一且稳定（不能依赖随机数或时间戳），尤其在列表循环中要加唯一上下文，比如
id="cart-item-{{userId}}-{{productId}}"
真正卡住团队的，往往不是“要不要用 BEM”，而是“这个 class 到底该不该属于那个 block”。命名不是贴标签，是做架构决策——每写一个 __ 或 --，都得问一句：这个边界，在下一个迭代里还会成立吗？
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
