Tailwind不是替代CSS选择器的工具，而是与之共存的样式层；其原子类无法覆盖基于DOM结构响应、穿透scoped/shadow DOM、复杂伪类组合三类场景，此时必须使用原生CSS选择器。
直接说结论：Tailwind 不是替代 CSS 选择器的工具，而是和它共存的层；强行用 @apply 或 !important 覆盖选择器逻辑，反而会让样式失控。真正“更好配合”的关键，在于分清边界、留出钩子、控制层级。
什么时候必须用原生 CSS 选择器？
Tailwind 的原子类无法覆盖三类场景，这时你绕不开选择器：
- 需要基于 DOM 结构动态响应（比如
:has(> .error)判断子元素状态） - 要穿透框架封装的 scoped / shadow DOM（Vue 的
>>>或 React 的::part()） - 实现复杂伪类组合（如
input:not([type="hidden"]):focus + label）
这些不是 Tailwind “不支持”，而是设计上就交还给 CSS 本身——它只管单节点样式，不管关系逻辑。
如何给 Tailwind 类留出选择器钩子？
别把所有 class 都塞进 HTML，尤其当你要用 JS 控制或 CSS 选择器干预时：
立即学习“前端免费学习笔记（深入）”；
- 用语义化 class 做“锚点”，比如
class="form-group js-validate"，其中js-validate不带样式，纯为 JS 或选择器定位 - 避免在同一个元素上混用大量 Tailwind 工具类 + 自定义选择器目标（例如
class="p-4 bg-gray-100 hover:bg-gray-200 form-field"），form-field应该是独立 selector，而不是视觉类的附庸 - 在 Vue/React 中，优先用
:deep(.child)或:where(.parent) .child替代全局污染式选择器，避免意外击中其他组件的同名类
为什么 @apply 在某些场景下比选择器更危险？
@apply 看似方便，但会悄悄破坏选择器权重和可预测性：
- 它把多个工具类内联成一条 CSS 规则，而这条规则的 specificity 和源顺序完全取决于你写
@apply的位置，不是 HTML 中 class 出现顺序 - 如果你在多个文件里对同一个 class 名用
@apply（比如都定义.btn），最后打包结果取决于 PostCSS 处理顺序，极易覆盖或遗漏 - CDN 引入方式下
@apply完全不可用，但开发者常误以为“写法一样就能跑”，导致本地开发正常、部署后样式消失
真正稳定的做法是：用 @layer components 显式声明作用域，并确保每个 @apply 块只在一个地方定义。
响应式与深色模式下选择器怎么不踩坑？
Tailwind 的 md:、dark: 是变体，不是媒体查询封装——它们生成的是带属性选择器或 class 的独立规则，比如：
.dark .btn { background-color: #1e293b; }
@media (min-width: 768px) { .md\:btn { padding: 0.5rem 1rem; } }
这意味着：
- 如果你自己写
@media (prefers-color-scheme: dark)，它和dark:变体是并行生效的，可能冲突（尤其当两者改同一属性） - 用
:is(.dark .btn, [data-theme="dark"] .btn)统一入口，比分散写两套逻辑更可控 - 不要在自定义选择器里重复写
dark:hover:bg-blue-800这种组合——Tailwind 已生成对应规则，你只需确保父容器有darkclass 或属性即可
最易被忽略的一点：Tailwind 的变体规则默认只作用于直系子元素，而你自己写的 .card .header 选择器没有这个限制。混用时，层级错位会导致暗色模式在嵌套结构中突然失效。
