p选择器仅适用于所有段落需完全统一基础样式（如重置margin、line-height）且无上下文差异的极窄场景；一旦需区分语义或上下文（如首页vs侧栏段落），应改用语义化类名如.paragraph。
什么时候该用 p 而不是 .paragraph
当你真需要「所有 p 标签都统一行高、字体大小、间距」时，p 才是合理选择。比如重置默认样式：p { margin: 0.5em 0; line-height: 1.6; }。但一旦出现「首页的 p 要大号字，侧栏的 p 要小号字」，标签选择器就立刻失效——它无法区分上下文。
常见错误现象：ul li a 看似精准，实则匹配所有嵌套层级的 a，包括面包屑、页脚链接甚至弹窗里的按钮；而 .nav-link 只作用于明确加了该类的链接，不越界。
- 标签选择器适合全局基础样式（如
body、h1～h6、blockquote） - 只要 HTML 结构稍有变动（比如把
p换成div），标签选择器就完全失灵 - 浏览器匹配时从右往左，
section article p这种长链会拖慢渲染，尤其在移动端
.btn 为什么比 button 更可靠
一个页面里可能有 button、input[type="submit"]、a role="button"，它们语义和用途不同，但视觉上都要像按钮。用 button 选择器只能覆盖第一种，剩下两种得额外写规则；而统一加 class="btn"，一条 .btn 就全收口。
类名还能组合：<button class="btn btn-primary btn-sm"></button>，靠 .btn-primary 控制颜色，.btn-sm 控制尺寸，互不干扰。标签选择器做不到这种正交控制。
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- 类名可复用、可叠加、可语义化（如
.is-loading、.has-error） - 拼错类名（
.bnt）不会报错，但样式不生效——这是最常被忽略的调试盲区 - 多人协作时，
button:hover和.btn:hover冲突概率远高于纯类名体系
ID 选择器 #header 在 CSS 中基本不该出现
不是语法错，而是工程风险高。哪怕你确认页面只有一处 id="header"，后续别人加个弹窗或 iframe 也可能意外引入同名 ID；一旦重复，document.getElementById('header') 只返回第一个，CSS 样式也只作用于第一个——行为不可预测。
真正需要 ID 的场景极少：锚点跳转（<a href="https://www.php.cn/link/0785d90297c165f28daa21244e98a139">FAQ</a>）、label[for="email"] 关联表单控件、或极少数 JS 需要精确单点操作的容器。这些都不该承担样式职责。
- CSS 中用
#header写样式，等于给未来埋了一个权重炸弹（优先级 100），后面想用.layout-header覆盖它，得写成.layout-header.header或加!important - Webpack/Vite 构建时若开启 CSS 模块化，ID 选择器无法局部作用域化，容易污染全局
- 自动化测试工具（如 Cypress）依赖稳定的选择器，
cy.get('#header')比cy.get('.header')更脆弱
类名命名别写 .red-text 这种描述性名字
需求一变就崩：.red-text 改成蓝色，要么改类名（牵扯所有 HTML），要么留着误导人。应该按功能或角色命名：.error-message、.section-title、.user-avatar。
更关键的是，类名本质是接口契约。当你写 <div class="card">，就承诺这个元素具备卡片应有的边框、阴影、内边距等特征；别人看到 <code>.card-header 就知道它是卡片的一部分，而不是某个随机红色文字。
- 命名中避免颜色、尺寸、位置等视觉属性词（
.big、.left、.center） - 允许用 BEM 风格：
.card__title、.card--featured，但别过度嵌套 - 类名重复完全合法，
class="btn btn-lg btn-primary"是常态，不是 bug
