rtl-val()函数比全局变量更可靠，因其每次调用均强制编译期条件判断并锁定值，避免因遗漏@include或硬编码导致的镜像断裂。
直接用 @use "@material/rtl" 是最稳妥的起点，但必须配合 html[dir="rtl"] 触发，且不能和手动 left/right 混用——否则翻转会漏、错、冲突。
为什么 rtl-val() 函数比全局变量更可靠
SCSS 编译时无法感知运行时 direction 变化，所以靠一个 $dir: rtl 变量全局切换，看似简单，实则脆弱：一旦某个组件忘了加 @include rtl(...)，或某处用了硬编码 margin-left，镜像就断了。而 rtl-val($ltr, $rtl) 是函数调用，每次使用都强制做一次条件判断，编译期就能锁定值。
- 必须定义为
@function，不能是$var—— 否则所有调用点都会得到同一个静态值 - 入口 SCSS 中统一设
$dir: ltr或$dir: rtl，构建时可通过环境变量注入（如 Webpack 的DefinePlugin） - 对非方向性属性（如
color、font-size）不传$rtl-value，函数内部自动跳过翻转逻辑
@use "@material/rtl" 的真实使用姿势
这个包不是开箱即用的“插件”，它只提供 Sass 层的 @mixin rtl 和 @function rtl-property，真正起效的前提是你的选择器能匹配到 [dir="rtl"] 祖先。比如你写 .card { @include rtl; }，它生成的其实是 .card { margin-left: 16px; } [dir="rtl"] .card { margin-right: 16px; }。
- 必须确保 HTML 根元素有
dir="rtl"，仅靠lang="ar"不触发任何规则 - 不要在同一个项目里同时引入
bootstrap.min.css和bootstrap.rtl.min.css—— 二者规则叠加会导致 margin 冲突 - 第三方组件（如日期选择器）不会自动响应
[dir="rtl"]，需单独加.my-datepicker[dir="rtl"] { transform: scaleX(-1); }并重置子元素文字
逻辑属性替代物理属性时的三个硬约束
用 margin-inline-start 替代 margin-left 是长期最优解，但它不是“写了就完事”。浏览器兼容性、父容器行为、继承链都可能让效果出人意料。
立即学习“前端免费学习笔记（深入）”；
-
margin-inline-start在无明确direction或writing-mode的容器中，行为不可预测 —— 必须确保其父级有dir="rtl"或direction: rtl -
float没有逻辑等价物，float: inline-start不被支持，只能继续用float: rtl-val(left, right)或重构为display: flex - 背景图路径、SVG 图标、伪元素箭头等不会随逻辑属性自动翻转，必须显式加
transform: scaleX(rtl-val(1, -1))，且若含文本需在子元素上补transform: scaleX(1)
构建双版本 CSS 的常见误操作
想输出 app-ltr.css 和 app-rtl.css 是合理需求，但 SCSS 不支持“编译时分支输出”。有人用 @if $dir == 'rtl' { @import 'rtl-overrides' }，结果导致两份 CSS 都包含全部规则，只是部分被覆盖 —— 这不仅体积翻倍，source map 也会错乱。
- 正确做法是用构建工具（如 Webpack、Vite）分别执行两次编译：一次传
$dir: ltr，另一次传$dir: rtl - 禁止在 SCSS 里用
@import做条件加载 ——@import是预处理指令，不是运行时逻辑，Dart Sass 已弃用它 - 如果必须单文件交付，优先用
[dir="rtl"]选择器做局部覆盖，而非生成两套完全独立的样式表
真正容易被忽略的是：RTL 不是“把 left 换成 right”这么机械，它牵扯图标语义、阅读节奏、交互预期。比如阿拉伯语用户习惯从右往左滑动轮播图，但 transform: scaleX(-1) 只翻转视觉，不改变事件流向 —— 这类细节，光靠 SCSS 编译解决不了，得结合 JS 行为层适配。
