微信小程序采用WXSS而非标准CSS，因其双线程架构下WXML不生成真实DOM，导致依赖DOM结构的CSS特性无法实现；rpx单位由客户端运行时计算，@import为编译期静态引入，style动态绑定需跨线程通信，所有样式最终映射为原生控件属性。
微信小程序没用标准 CSS，不是因为“不想兼容”，而是渲染模型和运行环境决定了它必须换一套思路。
WXML 渲染层不暴露 DOM，CSS 选择器天然受限
Web 页面里你可以用 document.querySelector('div:nth-child(2) > span:last-of-type') 精准抓取任意节点，因为浏览器提供了完整 DOM 树和遍历 API。小程序的 WXML 不生成真实 DOM，只在视图层维护一个轻量级节点树，且逻辑层（JS）和渲染层完全隔离——JS 无法访问、遍历或动态插入节点，所以像 :nth-child、:not()、::before 这类依赖 DOM 结构或伪元素的 CSS 特性，从底层就不可实现。
你看到的 WXSS 支持 .class、#id、view 这些基础选择器，是因为它们能被静态映射到组件实例；但一旦涉及运行时结构推断（比如兄弟元素关系），框架就无从下手。
rpx 单位强制绑定屏幕宽度，响应式逻辑下沉到框架层
Web 的 rem 或 vw 需要 JS 计算根字体大小或监听 resize，而小程序直接规定 750rpx = 屏幕宽度，由客户端原生计算并注入缩放系数。这意味着：
公众号运营｜微信公众号｜公众号一条龙｜公众号全流程｜自媒体运营｜微信自动化｜内容流水线｜AIGC 工作流 — 公众号一条龙运营总控入口，覆盖选题→撰稿→审稿→排版→配图→发布等8个子技能，单条指令即可完成从零到上架的完整图文。面向公众号编辑、自媒体等用户。
立即学习“前端免费学习笔记（深入）”；
-
rpx在编译期无法转成固定px，所有样式计算必须延迟到运行时 - 媒体查询（
@media）几乎没意义：你无法知道“宽屏”还是“窄屏”，因为宽度永远是 750rpx - 设计师按 iPhone6（375px 宽）出稿，开发直接写
100rpx就等于 50px —— 不需要 JS 适配层，也不允许你绕过这个约定
@import 和内联 style 的行为差异暴露了线程隔离本质
WXSS 允许用 @import 引入外部样式，但它只支持相对路径、不支持 URL，且导入时机在编译阶段完成；而 style 属性接收的是字符串表达式，例如 style="color: {{ textColor }};"，这个值会在逻辑层 JS 计算后，通过线程间通信传给渲染层解析。
这种割裂带来两个实际约束：
- 不能在
@import的文件里用{{ }}，因为它是纯静态编译 -
style中写大量动态计算（比如transform: translateX({{ offset * 2 }}px)）会触发频繁线程通信，性能比 class 切换差很多 - 所有样式最终都得转成客户端可识别的 native view 属性，所以
box-shadow在低端 Android 上可能被忽略，filter基本不支持
真正容易被忽略的点是：WXSS 不是“简化版 CSS”，它是为双线程模型定制的样式协议。你写的每一条规则，背后都对应着一次跨线程序列化或原生控件属性设置。试图把它当 Web CSS 用，迟早会撞上渲染层能力边界。
