/* ==== /css/design-tokens.css ==== */
/* ==========================================================================
达播工作台 Design Tokens — 浅色主题
三层结构：Primitive(A1) → Semantic(A2) → Component(B/C)
主色 #0064E0（Meta 钴蓝，替换原 TDesign 腾讯蓝 #0052D9）
规则：全站禁用裸 hex（仅 #fff/#000 例外），一律引用本文件 CSS 变量。
2026-09-06 底座重构（第十七轮）：
1) 色彩统一为 TDesign 官方单一色板 —— 清除 Apple iOS 系统色、Tailwind 图表色
2) 字号基准 13px → 14px（对齐 TDesign fontBodyMedium），全站正文不再发虚
3) 字重 510/590 → 500/600（PingFang/Noto SC 真实字重，消除合成加粗）
4) 阴影重做三档可感知层级，卡片不再只靠 1px 边框
========================================================================== */
:root {
/* ------------------------------------------------------------------
一、Primitive（A1-identity / A1-structure）—— 原始值，不直接用于组件
------------------------------------------------------------------ */
/* 主色 · Meta 钴蓝（500=主色 #0064E0；600=hover 深、700=active 更深） */
--color-primary-50: #E5EEFE; /* 激活底 / 选中 tint / 行 hover / KPI 蓝卡
⚠️ 2026-09-25 UI 美化试妆（方向 A · 品牌化清新）：由 #EDF4FE 加深。
**加深幅度受对比度硬约束**：本令牌作底时会与 --color-accent-text
（= primary-500 #0064E0）同框（base.css 的 .nav-item.is-active、
layout.css 的页标签、pages-finance 的 fin-chain__lab 等），
故必须满足「主色字 on 本底 ≥ 4.5:1」。
沿色相扫描后取最深合规值：本值 4.61:1（原 #EDF4FE 为 4.87:1，
更深的 #DEEBFE 会掉到 4.47:1 → 不合规，已否决）。
可见度：Δ通道 25（原 17）、L 94.7%（原 96.3%）—— 从"几乎看不出是蓝的"
变为明确的品牌浅蓝，一处改动作用于 49 处引用。 */
--color-primary-100: #DBE8FE;
--color-primary-200: #B9D3FD;
--color-primary-300: #94BBFB;
--color-primary-400: #5E9BF8;
--color-primary-500: #0064E0; /* 基准主色（Meta 钴蓝） */
--color-primary-600: #0457CB; /* hover（比主色深） */
--color-primary-700: #0040A3; /* active（更深） */
--color-primary-800: #002B73;
--color-primary-900: #001B4D;
/* 品牌青（2026-09-25 UI 美化 · 方向 A 新增）——
与 --color-chart-2 同值但**语义独立**：它是品牌色族的第二色，专供「蓝→青」渐变与点缀，
不要用它替代图表分类色（图表色有自己的一套成对维护规则）。 */
--color-brand-cyan: #029CD4;
/* 品牌渐变（方向 A「品牌化清新」的核心资产，2026-09-25 新增）
三档：主渐变（蓝→青）/ hover 深一档 / active 更深一档 / 柔底渐变（浅蓝→浅青，可铺大面积而不压内容）。
⚠️ 历史红线：只允许**同族**渐变（蓝→青，色相差约 18°，属相邻色），禁止跨色相（尤其 Indigo→Pink）。
⚠️ 渐变只用于「块级装饰」（横幅 / 主 CTA / 强调卡），**不得**用于正文文字（可读性）。
⚠️ 像素门禁 `tests/ui-token-standards.test.js` 对裸 hex 的例外只覆盖本文件 —— 故渐变的
三个色标全部写在这里，业务 CSS 一律 `var(--gradient-*)` 引用。 */
--gradient-brand: linear-gradient(120deg, var(--color-primary-500) 0%, var(--color-brand-cyan) 100%);
--gradient-brand-hover: linear-gradient(120deg, var(--color-primary-600) 0%, #0189BE 100%);
--gradient-brand-active: linear-gradient(120deg, var(--color-primary-700) 0%, #0177A6 100%);
--gradient-brand-soft: linear-gradient(120deg, var(--color-primary-50) 0%, #E4F4FB 100%);
/* 中性色 · TDesign Gray1-14（14 阶，CIELab 亮度均分） */
--color-gray-0: #FFFFFF;
--color-gray-50: #F3F3F3; /* Gray1 页面底 / hover 底 */
--color-gray-100: #EEEEEE; /* Gray2 */
--color-gray-200: #E8E8E8; /* Gray3 弱分隔线 */
--color-gray-300: #DDDDDD; /* Gray4 默认边框 */
--color-gray-400: #C6C6C6; /* Gray5 输入框描边 */
--color-gray-500: #A6A6A6; /* Gray6 禁用文字 */
--color-gray-600: #8B8B8B; /* Gray7 */
--color-gray-700: #777777; /* Gray8 */
--color-gray-800: #5E5E5E; /* Gray9 */
--color-gray-900: #4B4B4B; /* Gray10 */
/* 字体栈（全站唯一）
⭐⭐⭐ 2026-10-08 00:4x **补macOS 中文兜底**（真机撞到才补，不是预防性加料）
────────────────────────────────────────────────────────────────────────────────
起因：headless/自动化 Chrome 截图时，**中文全部画不出来**（图标正常、文字空）。
逐层排查结论（都排除了）：
· DOM 侧正常 —— `.nav-group-text` 的 w=135/h=19、深墨色、无溢出，**文字在**；
· 系统字体侧：`--font-family-body` = "Noto Sans SC", "PingFang SC", "Inter",
-apple-system, sans-serif，而**这台机器既没有 Noto Sans SC，也没有 PingFang SC**
（`/System/Library/Fonts/PingFang.ttc` 不存在）⇒ 落到通用 `sans-serif`
⇒ Chrome 自动化环境解析不出中文 ⇒ 文字空白。
⇒ 补`"Hiragino Sans GB"`（macOS 自带，/System/Library/Fonts/Hiragino Sans GB.ttc 实测在）
与 `"Heiti SC"` / `"STHeiti"` 两档兜底，**排在 sans-serif 之前**。
⚠️ **这不是"为了截图好看"**：任何没装 PingFang 的 macOS（老系统 / 精简环境 /
CI 容器）都会走到同样的坑 ⇒ 属于真实的健壮性缺口。
⚠️⛔ **顺序有讲究**：PingFang SC 仍是第一选择（乐哥在真机上看的就是它），
新增的只做**兜底**，一个都不许提到它前面 —— 换字形会影响他实际看到的观感。 */
--font-family-body: "Noto Sans SC", "PingFang SC", "Hiragino Sans GB",
"Heiti SC", "STHeiti", "Inter", -apple-system, sans-serif;
--font-family-mono: "JetBrains Mono", ui-monospace, "SF Mono", monospace;
/* 字号阶梯（对齐 TDesign：12 / 14 / 16 / 20 / 24 / 30 / 36）
正文基准 14px —— 中文在 12px 以下会发虚，禁止再降到 13px。 */
--font-size-xs: 12px; /* 辅助 / 徽章 / 时间戳 / 表头小字 */
--font-size-sm: 14px; /* 表格正文 / 次级正文（原 13px，2026-09-06 提升） */
--font-size-base: 14px; /* 正文 / 表单基准（TDesign fontBodyMedium） */
--font-size-lg: 16px; /* 卡片标题 / 强调（TDesign fontBodyLarge） */
--font-size-xl: 20px; /* 模块标题 */
--font-size-2xl: 24px; /* 页面标题 */
--font-size-3xl: 30px; /* KPI 数字 */
--font-size-4xl: 36px; /* 看板大数字（极少用） */
/* ⭐⭐⭐ 2026-10-08 15:3x 侧栏一级平铺项高 42 → **34**（与二级项同值）
────────────────────────────────────────────────────────────────────────────────
乐哥：「首页的这个选中框，和二级菜单的**大小不一样**，这个不对，改改，要一致」。
▸ 现状（真机）：`.nav-item`（首页）= 42、`.nav-item--sub`（我的报销/达人列表…）= 34
⇒ 两个选中/悬停胶囊**差 8px**，同一张侧栏里并排看得见（他截图里 首页 白胶囊
明显比 我的报销 那块高）。
▸ 取 34 而不是把二级抬到 42：**二级的 34 是今天（15:0x）刚按飞书定的新标准**
（飞书行高 34 + 4 缝），把二级改回 42 会反转当天最新的口径。
▸ 层级不靠高度表达：一级仍是 **15px/500**、二级 **14/400/`--color-muted`**
⇒ 体量、字重、颜色三维仍在。
⚠️⛔ **旧关系锁已废**：本条原写「必须等于 `--control-height-row`（= 对齐右侧悬浮 tab 栏 42）」
（乐哥 10-07 22:55 的要求）。**本次有意的方向反转** —— 侧栏菜单统一 34 之后，
「首页与 tab 栏等高」这条不再成立（tab 栏仍是 42，它属于页头控件那一档）。
门禁 `ui-1010-three-fixes` 已同步改为「**必须等于二级项高度**」。
⚠️ 为什么不复用 `--control-height-row`：那个管的是**页头筛选行**的搜索框/月份框/按钮，
语义不同；混用会让侧栏菜单高度被页头控件的调整带走。 */
--nav-item-h: 34px; /* 侧栏一级平铺项（与二级项同高，见上） */
/* ⭐⭐⭐ 2026-10-08 14:5x 侧栏**品牌区总高**（含菜单起始留白）—— 它就是那条边界线
────────────────────────────────────────────────────────────────────────────────
乐哥 14:30（截图 + 三句）：
① 「左边菜单栏文字的高度，按照我截图这个为标准做，就是红框线下面」
② 「logo 和文字看要不要整体下移」
③ 「如果菜单栏展开了很多，滑动的时候，也不要突破这个界限，如果突破的隐藏了」
▸ 真机像素级比对（同口径量「乐哥截图」与「本地渲染」，都按 CSS px）：
元素 乐哥截图 本地（旧，= 线上同版）
logo 顶部 y=16 y=12
品牌标题「星盟达人后台」 y=34 y=30
首个菜单项「首页」文字 y=105 y=118
⇒ 乐哥那条红线画在 **y=92**，而 92 正是**页头卡（`.page-header`）顶边**
（真机实测 `.page-header` top = 92）—— 菜单就从这条线下面开始。
▸ **本令牌 = 92**：品牌区一口气长到 92，菜单紧贴其下沿开始。
于是「品牌区下沿 = 菜单起始线 = 页头卡顶边 = 滚动裁切边」**是同一根线**。
⛔⛔ **为什么必须把留白并进品牌区、而不是继续当 `.sidebar__nav` 的 padding-top**
（这是乐哥第③条的**结构性**修法，不是调参）：
留白长在滚动容器**内部**时，滚动内容可以进入这段留白 ⇒ 菜单项上滑时会
出现在「logo 下方那段空档」里，只在容器外缘（品牌区下沿 y=60）才被裁住
⇒ 视觉上**越过了乐哥画的那条线**。并把留白并进品牌区后，滚动容器上缘 = 92、
裁切边 = 92 ⇒ 物理上滑不出去（不需要遮罩、不需要 JS）。
▸ 旧值 `--sidebar-nav-pad-top: 43`（= 103 − 60，对齐 tab 胶囊顶边 103.2）**已废**：
乐哥这次截图定的标准是 **92（页头卡顶边）**，比 103 高 11px。
⚠️ 改本值要连带核对：`--tabs-bar-height`(60)、页头卡 padding 10 + border 1（真机 92）、
以及 `.sidebar__nav` 的左右 12px —— 那 12 撑的是「竖向基线 62」，一个字都不能动。 */
--sidebar-brand-h: 92px;
/* 字重三级体系
注意：必须是 400 / 500 / 600 —— PingFang SC 与 Noto Sans SC 只有这三档，
用 510/590 会触发浏览器合成加粗，Mac/Windows 粗细不一致、字形边缘发毛。 */
--font-weight-regular: 400; /* Read */
--font-weight-medium: 500; /* Emphasize */
--font-weight-semibold: 600; /* Announce */
/* 行高 */
--font-line-height-body: 1.5;
--font-line-height-tight: 1.2;
/* 字距 */
--font-letter-spacing-body: 0;
--font-letter-spacing-display: -0.02em; /* ≥30px 标题 */
--font-letter-spacing-caps: 0.06em; /* ALL CAPS */
/* 间距（4px 网格，禁止 5/7/11/13 等离网格野值） */
--space-1: 4px;
--space-2: 8px;
--space-3: 12px;
--space-4: 16px;
--space-5: 20px;
--space-6: 24px;
--space-8: 32px;
--space-10: 40px;
--space-12: 48px;
/* ══════════════════════════════════════════════════════════════════════
控件高度 · **两档制**（2026-09-26 乐哥拍板「两档制」+「令牌化全局兜底」）
══════════════════════════════════════════════════════════════════════
⛔ 改前的乱象（真机实测 9 页）：输入框 3 档（28/34/44）、选择框 4 档
（28/30/34/44）、按钮 9 档（28/30/32/36/44/46/48/57/123）——
同一排里 28 / 30 / 44 三种高度并排（业绩总表工具栏最明显）。
⛔ 根因：2026-09-25 建了这三个令牌，但**几乎没用**
（--control-height 使用 0 处、-sm 5 处、-touch 1 处，而硬编码有 65 处），
且"紧凑档"只写在 4 个具体选择器里（`.toolbar--list` 等）——
**不是全局规则** ⇒ 任何新页面/新容器漏掉就回落 44px。
✅ 现在全站**只有两档**（内容区）：
· 标准档 44px —— 表单页 / 弹窗 / 页面头部主按钮（输入类操作，从容）
· 紧凑档 34px —— 列表工具栏 / 表格行内 / 分页区（信息密度高，34 刚好）
⚠️ 顶栏与侧栏**自成一套**、不在此两档内（顶栏 48 胶囊、侧栏 46 菜单行）——
它们由各自的作用域规则（`.page-tabs-bar .icon-btn` 等）自保，本令牌管不到。
⚠️ 用法纪律（避免又退回散写）：
· 控件高度**一律**写 `var(--control-height)` / `var(--control-height-sm)`
· 新增页面若把控件放进 `.toolbar`，**自动**是 34px（全局兜底已覆盖）
· 真要第三种高度时，先说明理由再加令牌，别就地写 px（那是乱象的起点）
══════════════════════════════════════════════════════════════════════ */
--control-height: 44px; /* 标准档：表单 / 弹窗 / 页面头部主按钮 */
--control-height-sm: 34px; /* 紧凑档：列表工具栏 / 表格行内 / 分页区 */
--control-height-touch: 40px; /* 历史遗留（手机端最小触摸目标）—— 见下方说明 */
/* ⭐⭐⭐ 2026-10-07 19:50 新增第三档「页头筛选行档」= **42px**
────────────────────────────────────────────────────────────────────────────────
▸ 为什么需要（乐哥 19:42 实报）：「搜索框，月份筛选框，还有右边新增排期的
高度和左边tab栏的不一样，你看下要视觉上一致」。
▸ 但**实测结论与他（和我的）截图里的印象不同**（1920 视口，含边框）：
tab 托盘 **42** ｜ tab 选中项 34 ｜ 搜索框 34 ｜ 月份框 34 ｜ 新增排期 34
⇒ **三个控件本来就完全一致**（都是 34），真正"高 8px"的是**托盘本身**
（`padding: 3px` + 2px 边框 = 34+6+2 = 42）。
⇒ 两条路可选：① 托盘降到 34（治本，但托盘那 3px 内距正是它托住胶囊的地方）
② **其他控件升到 42**（乐哥 19:45 拍板走这条）
⚠️⛔⛔ **为什么不是直接把 `--control-height-sm` 改成 42**：
本令牌被 **48 处引用、跨 8 个文件**（table.css 17 / pages.css 10 /
overlays.css 6 / layout.css 8 / pages-influencer.css 2 / components.css 2 /
cost-chart.css 1）—— 表格行内控件、分页、工具栏全都在用 34。
一改就是**「改外观顺手连累几何」**（本日铁律第一条，已犯三次）。
⇒ 另起一档，**只给页头筛选行用**（作用域由 layout.css 里那三条
`:has(.table-tabs--in-header)` / `.page-header--filter-bar >` 限定）。
⚠️ 为什么 42 而不是 44：44 是标准档，会让这一行比卡片内的紧凑控件高一档；
42 正好等于托盘的视觉高 ⇒ 整行中心线与外框全部对齐，且只比全局紧凑档高 8px
（页头本就比表格区宽松，这个量级不影响全站密度）。 */
--control-height-row: 42px; /* 页头筛选行档：与 .table-tabs--in-header 的 42 同源 */
/* 圆角阶梯（TDesign：3 / 6 / 9 / 12 / 9999，严格递增）
⭐ 2026-09-25 Gashora 像素级试妆：卡片 12 → **16px**、弹窗 12 → **20px**。
参考图（Gashora）卡片圆角实测 ≈16-20px——大圆角是"柔和、有呼吸感"的直接来源。
⚠️ 与表格内嵌改造配套：表头背景已去、表格不再贴卡片边 ⇒ 大圆角不会顶破表头。 */
--radius-none: 0;
--radius-sm: 4px; /* 徽章 / 小标签 */
--radius-seg: 6px; /* 分段控件 / 筛选 / Tab 项 */
--radius-md: 10px; /* 按钮 / 输入框 / 菜单行（2026-09-25：8 → 10，与卡片 16 协调） */
--radius-lg: 16px; /* 卡片（2026-09-25：12 → 16，Gashora 风） */
--radius-xl: 20px; /* 弹窗 / 抽屉（2026-09-25：12 → 20） */
--radius-pill: 9999px; /* 头像 / 状态胶囊 */
--radius-full: var(--radius-pill); /* 兼容别名，勿再新增 50% / 999px 写法 */
/* ⭐ 2026-09-26「内容分组 Tab」的托盘 —— 2026-09-28 全站升级为**白底胶囊 + 外框**
（乐哥：「所有页面 tab 胶囊这个 ui 不统一，有的有外框，有的没有，需要补进去」）：
原「灰托盘 + 选中白块」在**白底卡片/页头内**套灰底，与卡片语言割裂；
统一为「白底 + 1px 边框 + 圆角 16 + 选中渐变蓝胶囊」，与详情页 Tab 行 /
页头胶囊 / .seg 同一套语言（全站内容分组切换只此一套）。
用于：业绩总表「直播业绩/私域业绩」、达人详情、达人表单、新建排期/排期详情、
签约公司详情/表单、成本下钻弹窗、新增用户弹窗（共 11 处）。
⚠️ 令牌名保持 `--tab-tray-*`（改名会波及多处引用，收益低）；语义已更新为"胶囊容器"。
⚠️ 圆角 12 → 16（跟 --radius-lg 走）：白底卡形态下与卡片圆角同档才不突兀
（原 12 是"灰托盘"形态的取值 —— 那时它是独立的小控件，不与卡片并列）。 */
/* ⭐⭐⭐ 2026-10-07 13:40 改回 **Apple 灰托盘**（乐哥：「这个悬浮的tab不对，
首先tab的底色，**之前不是说用apple那种吗**」）
────────────────────────────────────────────────────────────────────────────────
▸ 为什么必须换：内容页现在是**纯白** `--color-surface`(#FFF)，而托盘也是纯白
⇒ 同色相接 ⇒ **托盘整个"化掉"**，看不出这是个选项组（实测截图：只剩胶囊和几个字）。
▸ Apple 的做法：托盘是**浅灰一层**，与白底内容卡拉开一档；选中项才是实心品牌蓝。
⇒ 层次变成「白内容卡 → 浅灰托盘 → 实心蓝胶囊」三级，选项组才读得出来。
⬇️ 取值 #F1F3F5：与 `--color-surface-2`(F1F5F9) 同族但更中性一档，
在白底上可见（Δ ≈ 10 阶，与 Apple 托盘的观感同档），又不会脏。
⚠️ 别写回 var(--color-surface)：那正是 10-07 上午"托盘看不见"的原因。
⚠️ 托盘变灰后，**未选中项**仍应是白底（不然灰底上再压一层灰更闷）——
hover 用 `--color-surface`（白），active 用品牌蓝实心。 */
--tab-tray-bg: #F1F3F5;
/* ⭐⭐⭐ 2026-10-08 15:3x **令牌已删除**（原 `--tab-tray-hover-bg` = rgba(255,255,255,0.55)）
──────────────────────────────────────────────────────────────────────────────
乐哥：「二级页面这个**白色的卡片**还没去除干净」——真机取证（他的截图 2582×1034，
沿胶囊中线逐点取色）：蓝块右侧紧邻约 50 CSS px 是 **(248,250,250)**，
正是 0.55 白压在灰托盘(241,243,245) 上的结果 ⇒ 那块"白卡"就是**鼠标悬停块**。
在灰托盘里，半透明白读起来仍像"第二个选中/一张白卡" ⇒ 干脆**不给底色**：
hover 只变文字色（与一级页胶囊 `.pill-filter__item:hover` 一直以来的做法统一）。
⚠️ 历史：10-07 是不透明白（会切断滑动的蓝块）→ 10-08 14:1x 降为 55% 半透明
（乐哥"粘滞感"那轮）→ **15:3x 直接去掉底色**。三次都是同一个东西在收窄。
⛔ 别再引入"hover 底色"：真要加，必须先想清楚它与滑动的 ink（首个子元素、绘制在最下）
的层叠关系（`.is-inking` 那套兜底仍保留在 pages-influencer.css，就是给这一天的）。 */
--tab-tray-active-bg: var(--color-surface); /* 保留：ink 指示块用（现已全站隐藏） */
--tab-tray-radius: var(--radius-lg); /* 12 → 16（与卡片圆角同档） */
--tab-tray-item-radius: 8px;
/* ⭐⭐⭐ 2026-09-28「克制玻璃」统一语言（乐哥：「顶栏透明度、左侧菜单栏、浮岛、
tab玻璃效果，看能不能统一同一套效果」）——
之前四处各自写值（顶栏 .72 单色 / 侧栏纯白不透明 / 浮岛 .70→.44 / Tab .66→.40），
数值漂移、观感不统一。现抽出四个令牌，**四处引用同一套**：
· --glass-hi / --glass-lo：透白渐变（上实下透 —— 光源从上来，玻璃上缘更亮）
· --glass-blur：模糊 + 饱和度（saturate 让穿过的色彩"活"起来，是玻璃质感的关键）
· --glass-lit / --glass-lift：上缘 1px 高光 + 外投影（浮起的"光边"）
⚠️ 透明度取 0.70→0.46：比"白 82%"透（能看出底下内容在动），
又比全液态玻璃（0.5→0.24）克制 —— 文字区仍清晰可读（管理后台的硬约束）。
⚠️ 玻璃只用于"浮在内容之上的层"（顶栏/侧栏岛/浮岛/吸顶 Tab）——
静态的卡片、表格**不许**用（它们不是浮层，加了会糊）。 */
--glass-hi: rgba(255, 255, 255, 0.70);
--glass-lo: rgba(255, 255, 255, 0.46);
--glass-blur: blur(20px) saturate(180%);
--glass-lit: inset 0 1px 0 rgba(255, 255, 255, 0.95);
--glass-lift: 0 8px 26px rgba(16, 24, 40, 0.14);
--glass-bg: linear-gradient(180deg, var(--glass-hi) 0%, var(--glass-lo) 100%);
/* ⭐⭐⭐ 2026-09-28「液态玻璃」（Liquid Glass，乐哥拍板选 **L3 浓液态** 档）
─────────────────────────────────────────────────────────────────────────────
用途：**全站 tab 条吸顶那一刻**的质感 —— 比上面的"克制玻璃"明显更强。
乐哥原话：「这个透白毛玻璃不行，做能液态玻璃那种」+ 三档里选了 L3。
▸ 与克制玻璃的差别（为什么另起一套而不是改 --glass-*）：
· 克制玻璃是**多个浮层共用**的日常语言（顶栏/侧栏/浮岛），0.70→0.46 很轻；
· 液态玻璃只在**"贴顶"这一个时刻**出现（乐哥：「刚进来应该没那么重的阴影吧，
是不是和其他内容叠加才有」）⇒ 它是"临时状态"的质感，两者语义不同，不能混用。
· 改 --glass-* 会连带改顶栏/侧栏/浮岛（那是乐哥已验收的形态）。
▸ 四层构造（液态玻璃的关键在**边缘**，不在模糊本身）：
① 斜向渐变底（135deg）—— 模拟光在玻璃里折射的走向（180deg 直下会显"塑料"）
② blur + saturate —— 让穿过的内容"活"起来
③ **四边内高光**（上/下/左/右各一条 inset）—— 这是"厚玻璃"的立边
（只做上缘 = 普通高光条；四边都做才有"一块玻璃"的实体感）
④ 内发光带（上下各一道大半径 inset 白）—— 玻璃的"厚度透光"
⑤ 双层外投影（近密 + 远疏）—— 浮起的量感
⚠️ 只在**吸顶态**挂载（`is-stuck`），静态页面零开销、零视觉影响。
⭐⭐ 2026-09-28 晚 调「真的看得出透」（乐哥：「这个悬浮 tab 透明度几乎不可见，
看不出是透明的，得能看得出来」）——
改前三项叠加把玻璃做成了"纯白"：alpha 平均 ~0.4 + blur(40) + **brightness(1.10)**，
而 tab 底下滚过的多是**白色卡片**（白+白+提亮）⇒ 与不吸顶的白底**几乎无差别**。
改后（三处同改，缺一不可）：
· alpha 0.52/0.26/0.42 → **0.40/0.15/0.30**（白色覆盖少一档，底下内容能透出来）
· blur 40 → **22**（40 会把穿过的一切抹成均匀一片，看不出"有东西在下面"）
· **去掉 brightness(1.10)**（它是"看着像纯白"的主因；提亮只该由内高光负责）
· saturate 220% → 150%（白底上高饱和无收益，降一档更稳）
⚠️ 可读性底线：玻璃上还要压 tab 文字，alpha 不能无限降 ——
再往下调（如 ≤0.25/0.08）会开始与背景内容"打架"。
⚠️ 改的是令牌 ⇒ `.tabs` / `.sf-tabs__track` / `.page-header--has-tabs` 三处吸顶态**同时**生效。
⭐⭐⭐ 2026-10-07 18:00 乐哥：「感觉好像有点奇怪，透明度和顶栏一样吗」
────────────────────────────────────────────────────────────────────────────────
▸ **实测**（真机 computed，两层紧挨着，肉眼一眼看出割裂）：
顶栏 `.page-tabs-bar` 白 0.70 → **0.46**（180deg 直下，blur20）
吸顶卡 `.page-header--has-tabs.is-stuck` 白 0.40 → **0.15** → 0.30（135deg，blur22）
⇒ 中段 **0.46 vs 0.15**，吸顶卡比顶栏**透近 3 倍**。
⇒ 截图里能直接看到 tab 卡后面**绿/粉/蓝色块透出来**，而顶栏是实心白 ——
上下两层紧挨着，却是两套完全不同的浮层语言 ⇒ 这就是"奇怪"的来源。
⚠️ 09-28 那次调"看得见透"的前提是「tab 底下滚过的是**白卡片**」；
现在内容区是**彩色状态标签/按钮**（已入驻/否/local:jerry…），
0.15 的中段会把它们整片透出来 ⇒ 那个前提已经不成立了。
✅ 改法：**只对齐顶栏的透明度档**（0.70 → 0.46），三档等比放大：
0.40/0.15/0.30 → **0.70/0.46/0.58**
· 0.70/0.46 = 顶栏 `--glass-hi` / `--glass-lo` 的**原值**（逐值对齐，不是约等）
· 0.58 = 首尾的中点，让 135deg 斜向仍保留"上缘更实、下缘更透"的玻璃感
⛔ **blur 22 与 135deg 都不许动**：
· blur 22 是 09-28 定的（40 会把穿过的内容抹成一片，看不出"下面有东西"）
· 135deg 斜向是"液态玻璃"与"普通毛玻璃"的分界（180deg 直下会显塑料）
这次只解决**透明度档位不一致**，不碰这两条已验收的设定。 */
--liquid-bg: linear-gradient(135deg,
rgba(255, 255, 255, 0.70) 0%,
rgba(255, 255, 255, 0.46) 48%,
rgba(255, 255, 255, 0.58) 100%);
--liquid-blur: blur(22px) saturate(150%);
--liquid-edge: rgba(255, 255, 255, 0.85);
/* ⭐⭐⭐ 2026-10-07 17:14 乐哥：「tab悬浮，不要搞那么重阴影吧，你看下我给你的这个
参考图，这个就是标杆」（Apple iPhone Duo 页面顶部那条吸顶卡）
────────────────────────────────────────────────────────────────────────────────
▸ **标杆的实测值**（用户提供参考图，逐像素量出来的，不是目测）：
卡片外侧**投影 = 0**。下缘外侧 y=129/130 是 2px 边框线（#E6E6E9），
再往下 y=131..174 **全 255 纯白** ⇒ 一点扩散都没有。
左缘外侧同理：x=238/239 是 2px 边框线，x=240..247 全纯白。
⇒ 标杆 = **白实体底 + 1px 淡线 + 零投影**，浮起感来自**边框**而非阴影。
▸ **原值的毛病**（就是乐哥说的"重"）：
`0 16px 44px rgba(16,24,40,0.22)` —— 透明度 **0.22** 是规范上限 0.07 的 **3 倍**，
44px 扩散落在 64px 高的卡上 ⇒ 上下左右糊出一圈灰雾，内容穿过时整行发灰。
叠加 6 条 inset 白色高光（合计白量 0.65/0.50/0.85×2/0.70）更是又厚又脏。
✅ 改法（三处同时生效：`.page-header--has-tabs` / `.tabs` / `.sf-tabs__track`
都读本令牌）：
· 外投影：**删掉 44px/0.22 那条**，换一条极淡的托地影
· inset 高光：**只留上下两条**（玻璃感所需的"上缘受光/下缘反光"），
删掉左右两条与两条大范围白色内发光
· 透明度全部 ≤ 0.07，与 §5.3「低透明度 + 大扩散」公式对齐
⚠️ 为什么保留一点投影而不是完全 0：卡片下方是**滚动内容**（表格行会穿过去），
零投影时内容贴着玻璃走、完全没有"托住"的感觉。基准图的 0 能成立是因为
下方本来就是纯白空背景 —— 我们的下方是**动的内容**，不能照抄 0。
⛔ 别再写回 0.1 以上的透明度：那就是乐哥说"重"的直接原因。
⭐⭐ 2026-10-07 18:00 乐哥：「然后要不加一点点阴影吧」
────────────────────────────────────────────────────────────────────────────────
▸ 上一版是 `0 2px 6px -2px rgba(...,0.07)`，实机下缘偏暗 19 —— 偏**轻**，
内容穿过时卡片没有"托住"的感觉。
✅ 加到 `0 3px 10px -3px rgba(...,0.10)`：
· 透明度 0.07 → **0.10**。⚠️ 超出 §5.3 建议区间（0.03~0.07）**是有意的**：
该区间针对的是"静态卡片浮起"，而这是**吸顶浮层压在滚动内容之上**，
需要更强的接触阴影才能读出"浮在内容上"。属场景差异，不是回退。
· 模糊 6 → **10px**、spread −2 → **−3**（更大更散，不是"贴边一圈"）
· 仍远小于 17:14 那版的 44px/0.22（那版才是乐哥说"重"的）
· inset 两条（0.85 / 0.55 白）**保持不变** —— 那是玻璃边缘受光，不属于"阴影"。 */
--liquid-shadow:
inset 0 1px 0 rgba(255, 255, 255, 0.85),
inset 0 -1px 0 rgba(255, 255, 255, 0.55),
0 3px 10px -3px rgba(16, 24, 40, 0.10);
/* 内层小框（装胶囊的那圈）在液态玻璃上的形态 —— 乐哥：「内层小框做」：
白卡变玻璃后，小框如果还是**不透明白底**，就像"玻璃上贴了张白纸"（实测踩到）。
这里给它**更透的白 + 更亮的边**，与外层玻璃形成两层玻璃的层次。 */
/* ⭐⭐⭐ 2026-10-07 15:50 30% 半透明白 → **32% 半透明蓝灰**（乐哥：「tab栏浮动的那个透明，
你改没了，加回来」）
────────────────────────────────────────────────────────────────────────────────
▸ 病根：常态托盘是 **Apple 灰 `--tab-tray-bg: #F1F3F5`（实体）**，
而吸顶时被换成 `rgba(255,255,255,0.30)` = **30% 半透明白**
⇒ 托盘底色在吸顶时**整个化掉**（与 13:45「托盘白底化掉」同一类病，
只是这次发生在**吸顶态**）。
真机实测：吸顶后托盘 computed background 变 rgba(255,255,255,.3)，
底色/边框层次读不出来，看起来像"tab 栏的底没了"。
▸ 新值 `rgba(227, 238, 251, 0.32)`：**色相跟着 `--tab-tray-bg` 的 #E3EEFB 走**
（同一支蓝 ⇒ 常态与吸顶是"同一个蓝"在不同透明度下），
透明度 0.32 让底下的表格内容**仍能透出**（玻璃的前提）。
⚠️ 别用纯白半透明：那会让托盘在吸顶时偏白，与常态的蓝灰脱节 ⇒ 两态不像同一套。
⛔ 别改成不透明（alpha=1）：那就失去"浮动透明"的效果了。 */
--liquid-tray-bg: rgba(227, 238, 251, 0.32);
--liquid-tray-edge: rgba(255, 255, 255, 0.62);
/* 顶部区（第一行）的高度。
▸ 2026-09-19 结构重排后，**全页顶部只有一行**（面包屑那行已撤，标签栏升为第一行），
所以本值与 --header-height 相等，二者都指"顶部那一行"。
⚠️ 为什么仍保留两个令牌：`--header-height` 还被 analytics.js 的 headerHeight()
读来当**吸顶高度**（它只关心"顶部占多高"，不关心归谁）；
而本令牌描述"标签栏 / 品牌区这一行多高"。两者当前同值、语义不同，别合并。
▸ 高度按下述三次调整，**每次都要连着标签体量一起改**（只改栏高会让标签显小）：
① 2026-09-19 晚 56 → 60（乐哥：「顶栏要不再高一点点？现在感觉有点挤」）。
⭐ 实测："挤"的主因**不是栏高而是间距** —— 工具按钮间只有 2px、标签间 4px。
那次是**三处一起调**才见效：栏高 56→60、标签 36→40、间距 2/4→6/6。
② 2026-09-20 60 → 52（乐哥：「最上面的标签，是不是太大，太占位置了」）。
⭐ 本轮实测出的客观依据（这才是"太大"的硬证据，不是感觉）：
· 标签 40px **比全站所有按钮都大** —— `.btn`=36、`.btn--sm`=30；
· 标签栏内图标钮 40px **比全站 `.icon-btn` 基准 36 大**（100 处在复用它），
标签栏是**全站唯一**把它放大到 40 的地方；
· 栏高 60px 是全站最高的横条。
⇒ 收回高度、**间距 6px 一个字不动**（上一条已证间距才是治"挤"的药）。
栏 52 / 标签 34 / 图标钮 36：标签上下各留 9px，仍比图标钮大一圈、不显小，
量级与 Chrome 浏览器页签相当。内容区起点 84 → 76，**每屏净赚 8px**。
③ 2026-09-26 96 → 84（乐哥：「顶部的菜单高度，稍微矮一点点吧」）。
⭐ 收到 84 的依据是**实测内部最高元素**（不是拍数字）：
顶栏内最高的可交互元素 = `.page-tabs-bar__tools`（含「我的」胶囊）**58px**、
logo 46px ⇒ 96px 时上下留白各 19px，明显偏松（顶栏像"一条厚带子"）。
收到 84 ⇒ 上下留白各 13px，仍比"贴边"宽裕，但顶栏不再压住首屏。
⚠️ 为什么只减 12 而不是减更多：**58px 内容 + 2×13px 是这套内容的舒适下限**——
再往下（如 76）留白只剩 9px，搜索胶囊/头像几乎顶到上下边缘，会重新变成
2026-09-19 那次"挤"的观感（乐哥当时反馈过）。
④ 2026-09-26 84 → **72**（顶栏 A6 定稿，乐哥逐轮拍板：原型 .tmp-check/topbar-proto/）。
⭐ 这次不是孤立收高度，是**整套重构**，内容物全部重排（详见 layout.css 顶栏段）：
· 多标签导航恢复（9-25 隐藏的那套 DOM/逻辑原样启用，只删 display:none）；
· 搜索 300px 胶囊 → 40×40 图标盒（乐哥：「搜索改成图标吧，不要输入框了」）；
· 「我的」胶囊 → 40px 纯圆头像（乐哥：「改成一个圆圈，里面只有头像」）；
· 铃铛/搜索/头像统一 40×40「有框无底」（1px 描边、透明底）；
· 栏体改半透明毛玻璃（乐哥：「顶栏做一点透明，正文内容滚上去时更好看」）。
⭐ 高度的依据同样是**实测**：原型先在 64px 上验证（乐哥：太矮不协调），
加到 72 ⇒ 控件 40px 上下各留 16px（与 84/58 的 13px 同档，不挤不空）。
⚠️ 历史调过的"挤/空"两个方向仍由 tests/page-tabs.test.js 的 H1/H2 锁着，
本值再调时不需要改断言（它们锁关系不锁数值）。
⚠️⚠️ 改本值**必须同时**改 `--header-height`（下方 137 行）—— 两处不同值会让
分析页 `/analytics` 的目录条 sticky 错位（它读 --header-height 当吸顶高度：
`top: var(--header-height)`，而它要贴在标签栏下沿）。
⇒ 两值同源，改一个必须改另一个。公式：`--header-height = --frame-gap + --tabs-bar-height`
（由 tests/restruct-topbar.test.js 的 C1 静态锁住，漏改会立刻红）。
⚠️ 侧栏 top / 内容区 margin-top / 品牌区高度 / 标签栏高度**四处都是 `calc()` 或
`var()` 引用本令牌**，改一处自动全跟 —— **不要**去动那四处（它们本来就该跟着变）。 */
--tabs-bar-height: 60px; /* ⭐⭐ 2026-10-06：72 → **60**（**去掉多标签**，顶栏只留
「品牌 ／ 页面定位（面包屑）／ 右侧工具」三段，与参考图一致）。
依据：顶部不再有标签行 ⇒ 60 = 控件 40 + 上下各 10。
⚠️ 手机端本来就是"无标签"形态（≤768px 块里隐藏标签格），
本次只是**把那套形态提到桌面**。
历史：56→60（09-19）→52（09-20）→76→88→96（09-25）→84→72（09-26）→60。
作顶栏高度的唯一来源。 */
/* 阴影三档（可感知层级：卡片 md、悬浮/下拉 lg、描边 ring）
⭐ 2026-09-25 Gashora 像素级试妆：全面**调柔调散**——参考图卡片阴影极淡但分明浮起，
旧值 opacity 偏高、偏移偏小 ⇒ 阴影"贴"在卡片下缘显脏。改为低透明度 + 大扩散。 */
--shadow-flat: none;
/* ⭐⭐⭐ 2026-10-08 与 `--shadow-card` **同批修正 Y 偏移归零**（乐哥：「下面比其他几个边重，
这个得做一样」——见下方 shadow-card 处的完整说明）。
`--shadow-sm` 实测用在：tab 托盘的滑动白块（pages-influencer）/ 圆形翻页按钮（pages-finance）/
快捷入口与取景框的 hover 态（pages）—— 全是"小卡片/小控件"，同样有下重问题，一并归零。 */
--shadow-sm: 0 0 2px rgba(16, 24, 40, 0.03), 0 0 3px rgba(16, 24, 40, 0.04);
--shadow-md: 0 2px 4px rgba(16, 24, 40, 0.03), 0 8px 20px rgba(16, 24, 40, 0.05);
--shadow-lg: 0 4px 8px rgba(16, 24, 40, 0.04), 0 16px 40px rgba(16, 24, 40, 0.07);
--shadow-ring: 0 0 0 1px var(--color-border);
--shadow-raised: var(--shadow-lg); /* 旧名兼容别名 */
/* 卡片浮起（苹果式）：0.5px 发丝线 + 大而散的柔影。用在纯白底弹层内的模块卡——
白底上没有明暗差可用，只能靠这一层影把卡片"托"起来（浅灰底不适用，会显脏）。 */
--shadow-card-float: 0 0 0 0.5px rgba(16, 24, 40, 0.12), 0 1px 3px rgba(16, 24, 40, 0.04), 0 10px 22px rgba(16, 24, 40, 0.08);
/* ⭐⭐⭐ 卡片浮起（2026-10-07 乐哥选「A 档」：把 20px 模糊收掉）
────────────────────────────────────────────────────────────────────────
参照系与实测依据（不是审美猜测）：
· 乐哥给的 Apple 参照图里，**白卡边缘过渡实测只有 1 格**（灰度 246 → 255 一步到位）
⇒ 卡片的"干净"来自边界清晰、不扩散。
· 改前配方 `0 1px 2px .03, 0 8px 20px .05` 实测（dpr2 逐物理像素扫卡片右缘）：
255 → 237（边框）→ 246 → 248 → 250 → 251 …爬 **13~25 个 CSS px** 才回到底盘色
⇒ 边框外一大片灰雾，这就是乐哥说的「没咱们的这么重」。
· 改后配方（下方值）实测扩散收敛到 **约 3 格（1.5~2 CSS px）**，与 Apple 同档。
⚠️ 为什么以前是 20px：当时底盘接近白（色差仅 9 阶）、色差托不住层次，
被迫用宽扩散造"浮起"。现在保留一条 1px 贴合影（勾边界）+ 4px 淡扩散（托起），
边界依然是"一根线"。
⛔ 别写回 20px：那会让每张卡外面都罩一片灰雾，卡片多时页面发闷。
⚠️ 与 `--shadow-card-float`（弹层内的模块卡，带 0.5px 发丝环）仍是两档：
那个用在纯白底上需要更强自我勾边；这个用在外层卡片上，越轻越好。
⭐⭐⭐ 2026-10-08 乐哥：「悬浮阴影是不是下面比其他几个边重啊，这个得做一样，
都和上面那个边一样」（达人详情·佣金配置里的白卡，实测截图圈出）
────────────────────────────────────────────────────────────────────────
🐞 根因：两道影的 **Y 偏移都是 +1px** ⇒ 阴影整体下移 ⇒ 下边缘可见、
上边缘几乎被盖住 ⇒ 视觉上"下边比上边重"。
（`0 1px 2px` 离上边缘只剩 2−1=1px 的可见带，离下边缘有 2+1=3px。）
✅ 改法：**Y 偏移归零**（`0 1px` → `0 0`）—— 上下左右各 2px / 4px 完全对称。
⚠️ 为什么不是"把下边也变没"（直接删掉贴合影）：卡片的边界感来自
"极淡贴合影 + 1px 实边框"的组合，删掉影会让白卡在浅底上"贴不住"。
对称后四边各有一圈同样淡的影，恰好是乐哥说的"四个边一样"。
⚠️ 只改 Y 偏移、**不动模糊与透明度**（0.03/0.05）—— 那是 10-07 按 Apple
参照图逐像素标定的（扩散收敛到 1.5~2 CSS px），改了就把那次成果推翻。 */
--shadow-card: 0 0 2px rgba(16, 24, 40, 0.03), 0 0 4px rgba(16, 24, 40, 0.05);
/* ⭐⭐ 2026-10-08「选中态浮起」—— 乐哥动效第②条：「选中要有悬浮突出效果」。
语义：**选中的胶囊 = 浮在托盘上的一小块**（与侧栏选中项的"白卡浮起"同一套语言：
都是"选中的那个东西离底更近一层"）。
▸ 为什么投影带**品牌蓝**而不是中性黑：胶囊底是品牌渐变，中性黑影落在蓝上会发灰
发脏（与 `.btn--primary:hover` 投影同一条经验：同色系 rgba(0,100,224,…)）。
▸ 量级（2px/6px、.28）是**四档实拍对比**选的（无 / 1-3-.20 / 2-6-.28 / 2-8-.35）：
1-3-.20 在 1x 下只差 2 个灰阶、肉眼读不出"浮"；2-8-.35 开始发重；
**2-6-.28 是"看得出浮起、又不脏"的档**（截图见 deliverables/选中浮起-改前改后）。
⚠️ 只给**选中态**，未选中项不加影 —— 一排全浮 = 全没浮（对比才是"突出"的来源）。 */
--shadow-pill-active: 0 2px 6px rgba(0, 100, 224, 0.28);
/* ══════════════════════════════════════════════════════════════════════════
动效（2026-09-26 全站升级 · 乐哥：「要求轻盈灵动，看着自然舒服，
不要那种傻快傻快的效果」）
──────────────────────────────────────────────────────────────────────────
⭐ 「傻快」的根因不是时长不够，是**曲线**：原来只有一条
`cubic-bezier(0.2, 0, 0, 1)`，进出共用 —— 它头尾都偏"硬"，
动起来像"被推着走完"，所以显得机械。
⭐⭐ 现在按**用途**分三条曲线（这是"轻盈"的主要来源）：
┌────────────────┬──────────────────────────────┬──────────────────────┐
│ 用途 │ 曲线 │ 为什么 │
├────────────────┼──────────────────────────────┼──────────────────────┤
│ 进场 / hover │ cubic-bezier(.22, 1, .36, 1) │ 开头快、尾巴长： │
│ --motion-ease │ = easeOutQuint │ 立刻有反应，落地是 │
│ │ │ "滑进去"而不是"刹住" │
│ 位移 / 形变 │ cubic-bezier(.65, 0, .35, 1) │ 两端都缓：位置在变 │
│ --motion-ease- │ = easeInOutQuad │ 的东西（指示块、宽度）│
│ in-out │ │ 起停不吃力 │
│ 退场 │ cubic-bezier(.4, 0, 1, 1) │ 干脆收走 —— 离场拖泥 │
│ --motion-ease- │ = easeInQuad │ 带水会让人觉得"卡" │
│ exit │ │ │
└────────────────┴──────────────────────────────┴──────────────────────┘
⚠️ 时长只从 150/200/300 微调到 **160/240/340**（+7%~13%）——
不是靠"变慢"来显得柔和（那会变成迟钝），而是靠曲线 + 位移量 +
错峰（见 --motion-stagger）。慢一点点的同时"尾巴"更长，观感才轻。
⚠️ `--motion-ease-standard` 是**兼容别名**（全站 133 处在用，几乎全是**颜色类**过渡：
background-color / color / border-color / box-shadow）。⛔ 不要删它：
删了那些地方会静默回退成浏览器默认的 `ease`（无报错）。
⛔⛔ **它不能指向带过冲的曲线**（2026-09-26 修，乐哥实报）——见下方专节。 */
--motion-fast: 110ms; /* hover / active / 选中 / 按压反馈（立刻跟手） */
--motion-base: 155ms; /* 小浮层：下拉 / 行内菜单 / 日期面板 */
/* ══════════════════════════════════════════════════════════════════════════
⭐⭐ 2026-10-17 侧栏一级菜单「折叠」专用档（手风琴）
──────────────────────────────────────────────────────────────────────────
乐哥：「手风琴的动画傻快傻快的，你优化下，要 iOS 那种优美的感觉」。
▸ 为什么原来的观感是"傻快"：折叠用的是 `--motion-base`(155ms) +
`--motion-ease-in-out`。155ms 是**小浮层**（下拉/日期面板）的档，
而 iOS 的列表展开大致在 300-400ms；更关键的是那条曲线**带 3.85% 过冲**
（为"灵动"设计的），用在**高度形变**上会读作"顶一下再落回来" —— 急。
▸ iOS 的做法（SwiftUI / UIKit 默认的 "smooth"）：
· 时长 0.35s 左右（比浮层长一倍，能看清"拉出来"的过程）
· 曲线 `cubic-bezier(0.32, 0.72, 0, 1)`：起手快、收尾极缓，**不过冲**
· 收比展利落一点（iOS 收起普遍比展开快 20% 左右）
⇒ 三个值都照这个来。⛔ 别复用到别处：这是"高度形变"专用的档，
弹层/下拉用它会显得拖沓（它们要"立刻跟手"）。
⚠️ 与 `--motion-base` 的关系：**不动**那个变量（全站 39 处引用）。
这里只新增，避免"调一个折叠把全站弹层都拖慢"。 */
--nav-fold-dur: 360ms; /* 展开 */
--nav-fold-dur-close: 290ms; /* 收起（略快，收要利落） */
--nav-fold-ease: cubic-bezier(0.32, 0.72, 0, 1); /* iOS "smooth"：起手快、收尾缓、无过冲 */
/* ⭐⭐⭐ 2026-09-29：**大浮层档被激活**（220 → 300ms）。
─────────────────────────────────────────────────────────────────────────────
🐞 根因（逐帧实测 + 全站 grep 发现）：本令牌注释写着"跨屏 / 大面板"，
但 **全站 0 处引用** —— 弹窗/抽屉当初误用了 `--motion-base`(155ms)。
而 C 档曲线（pop，y1=1.68）在 **t=0.25 就走了 91%**：
定格实测弹窗 **60ms 就已完全到位**，整段 155ms 里**只有 45ms 可见运动、
110ms 是空转**（元素已静止，动画在等时间走完）。
⇒ 观感是"啪地一下冒出来"，不是"从容地展开"——乐哥：「要自然」。
⭐ 现在按 Apple 官方浮层的节奏分层：**大浮层 300ms + 无过冲曲线**
（`--motion-ease-sheet`）—— 到 50% 用 49ms、到 99% 用 216ms，
**眼睛能看到完整过程**，且落位平顺不回弹。
⚠️ 为什么不用 base：155ms 配无过冲曲线，可见运动只有约 111ms，
仓促感仍在；300ms 是 Apple sheet/modal 的实际时长区间（300~350ms）。
⚠️ 分层纪律（照做，别一改全改）：
· 大浮层（弹窗 / 抽屉 / 搜索弹层）→ `--motion-slow` + `--motion-ease-sheet`
· 小浮层（下拉 / 行内菜单 / 日期面板）→ `--motion-base` + `--motion-ease-sheet`
· 小物件蹦一格（开关滑块）→ **保留 `--motion-ease-pop` 的过冲**，那是它该有的手感 */
--motion-slow: 300ms; /* 大浮层：弹窗 / 抽屉 / 搜索弹层（原 220ms，从未被引用） */
/* ⭐⭐⭐ 2026-10-08 00:5x **页面进场专用时长**（Apple 官网式渐显）
* ────────────────────────────────────────────────────────────────────────────────
* 乐哥：「页面切换…我们应该做 apple 官网那种渐变显示」。
* ▸ **为什么不能复用 `--motion-base`(155ms)**：那是**小浮层**的档
* （下拉 / 行内菜单 / 日期面板，见上面 C 档三档的分工）。
* 页面进场是**大���面**、且是用户主动等待的那一下 ⇒ 用小浮层的档必然读成"闪"。
* ▸ **420ms 的取法**（不是拍的）：Apple 官网产品页的段落进场约 400~600ms；
* 取**下沿 420** —— 再慢会让"点菜单 → 看到内容"的等待感变得明显，
* 而这个页面的内容量（表格几十行）本身就偏重，慢一点反而更协调。
* ⭐ 2026-10-08 乐哥：「Apple 渐显速度太慢了，稍微快 10%」⇒ **420 → 378ms**（420×0.9）。
* ⚠️ 只动时长，**曲线/位移不动** —— 快慢是时长维度，"弹不弹"是曲线维度，别一起动。
* ⚠️⛔ **为什么必须单独一档，而不能就地改 `--motion-base`**：
* `--motion-base` 全站 133 处引用（几乎全是弹层/下拉）。
* 改它 ⇒ 所有下拉、菜单、日期面板一起变成 420ms ⇒ 全站变"黏"。
* ⚠️ 这就是「**动效语言分层**」：同一套语言里，"小浮层快"与"页面慢"是并存的两档。
* ⚠️ 配套：曲线与位移在 base.css 的 `@keyframes page-fade-in` 里同时改了
* （pop→standard 无过冲、位移 12→8、scale 0.985→0.995），
* **时长与曲线必须成对改** —— 只改时长不换曲线，"弹一下"的感觉会留着。 */
--motion-page-enter: 378ms;
/* ⭐⭐⭐ 2026-10-08 00:6x **切换标签专用时长**（内容左右滑动）
* ────────────────────────────────────────────────────────────────────────────────
* ▸ **为什么不能复用 --motion-page-enter(378)**：
* 两者是**频率完全不同的两个动作**——
* · 页面进场：一天几十次（点侧栏菜单），可以慢、要有"浮现"的仪式感；
* · 标签切换：一天几百次（在几个页之间来回跳），420ms 会觉得**黏**。
* ⇒ 250ms：够读出"往哪个方向换页"，又不拖沓。
* ⚠️ 这条与上面那条是**同一课的两个面**：
* 「同一套动效语言」≠「所有动作同一档」。
* **无方向性的动作幅度小、时长可长；有方向性的动作幅度大、时长要短。**
* （今晚已在页面进场上吃过教训：位移 12px + pop 曲线 = 读作"弹"而不是"浮现"。） */
--motion-tab-slide: 250ms;
/* ⭐⭐⭐ 2026-09-26 第三版：**C 档「活泼」定稿**（乐哥：「动画用 c」）─────────────
定稿过程（两轮调参 → 三档在线试用 → 老板拍板）：
v1 150/200/300 + 单曲线 → 乐哥：「不要那种傻快傻快的效果」
v2 160/240/340 + 三条曲线 → 乐哥：「**还是不够灵动**」
⛔ 那次误诊了：把"不灵动"归因于时长，于是**拉长**到 240ms。
真因是**位移曲线慢起步**（`cubic-bezier(.65,0,.35,1)` 的 y1=0）——
逐帧实测前 2 帧只走了 1px。**加长时长只会让"糊"更明显。**
v3（本版）= B 档「灵动」 + C 档「活泼」，在真实系统里用 `?motion=` 现场对比
⇒ 乐哥选了 **C**（更短时长 + 更大的落位过冲）。
⚠️⚠️ **两条曲线的分工是本版的核心**，别把它们合并成一个：
· 位移（`--motion-ease-in-out`，y1=1.34 / 过冲 **3.85%**）
用于"滑过去"的元素（tab 指示块、抽屉）——
真机实测：86px 行程上过冲 **3.3px**，读作"落位时轻咬一下"，不读作"没对准"。
· 弹入（`--motion-ease-pop`，y1=1.68 / 过冲 **13.61%**）
用于"从无到有"的元素（卡片入场、列表行、开关滑块、弹窗缩放）——
它们没有"对准"语义，过冲大一点才生动。
真机实测：弹窗缩放峰值 1.0078（880px 宽上 ≈ 7px），温和。
⇒ 实测依据：两组过冲都是"肉眼刚好读出生命力"的量级；
再往上（位移 y1≥1.45 / 弹入 y1≥1.85）就会被 tests/motion-system.test.js 抓红。
⚠️ 过冲**只在落位段**，起手段仍是"立刻走"（t=0.25 时已走 91%）——
这是"灵动"的来源，别为了"稳"把起步改慢。 */
--motion-ease: cubic-bezier(0.2, 1.34, 0.4, 1); /* 进场 / hover（快起 + 过冲）——**只给位移用** */
--motion-ease-in-out: cubic-bezier(0.2, 1.34, 0.4, 1); /* 位移 / 形变（同源，保证语言统一） */
--motion-ease-exit: cubic-bezier(0.5, 0, 0.9, 0.6); /* 退场（**慢起**快收，不抢戏） */
/* ⭐⭐ 2026-10-08 14:x **滑行曲线**（慢起慢收、无过冲）—— 专给"指示器平移"用（当前仅
`.tabs__ink`，即 tab 选中框）。
⚠️ **为什么不复用 --motion-ease-in-out**：那条是"**快起** + 落位过冲"（乐哥要的"灵动"，
注释里还明确写"别为了稳把起步改慢"）。但乐哥对 tab 选中框的要求是
「**丝滑**地滑到下一个选中框」—— 实测：快起曲线下 **45ms 就走完 76% 行程**，
读作"唰一下到位、几乎看不见过程"，与"丝滑"正好相反。
▸ 语义分工（两条曲线各管一类动作，不是"两套语言"）：
· **位置变化**（页面进场 / 内容面板 / 卡片落位）= 灵动（快起 + 微过冲）
· **指示器平移**（选中框从 A 滑到 B）= 丝滑（两端缓、中段匀速）
▸ 取值 `cubic-bezier(0.45, 0, 0.25, 1)`：起步与落位各占约 1/4 行程，中间匀速滑行
（Material 的 standard easing 档），全程可读、无过冲。 */
--motion-ease-glide: cubic-bezier(0.45, 0, 0.25, 1);
/* ⭐⭐⭐ 2026-09-26 **颜色类专用曲线（无过冲）** —— 乐哥实报「鼠标移到菜单上，
选中框会快速闪好几次」的修复。
──────────────────────────────────────────────────────────────────────────────
🐞 事故链：v3 定稿时把本别名指向了 `--motion-ease`（带过冲 y1=1.34），
本意是让历史那 133 处 hover/选中态"自动升级、更灵动"。
⛔ 但**过冲曲线用在颜色上 = 闪**：颜色分量会冲过目标色再回落。
逐帧实测（hover 侧栏菜单项，.tmp-check 对照实验）：
· 过冲版：bg 冲到 **rgb(249,254,255)**（比目标 241,245,249 还亮）→ 再回落；
文字色冲到 **rgb(27,29,31)**（比目标更黑）→ 再回 —— 人眼读作"闪一下"；
鼠标滑过几个菜单项就连闪几次。
· 无过冲版：全程**单调趋近**目标色，不冲过头。
⇒ 颜色的"过冲"没有任何视觉意义（不像位移有"落位"语义），只会闪。
⭐ 本值 `cubic-bezier(0.2, 0, 0.2, 1)`（easeOutQuad 类）：无过冲 + 快起缓收，
与 --motion-ease 共享 x1=0.2 的起手节奏（语言统一）。
✅ 分工（记住这三条，别再合并）：
· 颜色 / 状态 / 布局尺寸（本值）—— **绝不过冲**
· 位移 / 形变（--motion-ease-in-out，过冲 3.85%）—— 滑过去的元素
· 弹入（--motion-ease-pop，过冲 13.6%）—— 从无到有的元素
⚠️ 由 tests/motion-system.test.js 静态锁住"本值必须无过冲"（反向注入有牙），
想用过冲请显式引用 --motion-ease / --motion-ease-pop。 */
--motion-ease-standard: cubic-bezier(0.2, 0, 0.2, 1);
--motion-ease-pop: cubic-bezier(0.34, 1.68, 0.5, 1); /* 弹入（落位回弹，约 13.6%） */
/* ⭐⭐⭐ 2026-09-29 **浮层曲线（Apple 式，无过冲）** —— 乐哥：「动效参考 Apple 官方的，要自然」
─────────────────────────────────────────────────────────────────────────────
🎯 为什么另起一条而不是改 `--motion-ease`：那条（pop，y1=1.68 / 过冲 13.6%）被
**开关滑块**等"小物件蹦一格"的场景使用 —— 过冲对那类是正确的（东西真的"蹦"进格子）。
浮层不是"蹦"，是"展开"：带 14% 回弹会读成"弹一下才落定"，与 Apple 的从容不是一回事。
⭐ Apple 的"自然"来自两点（**都不是回弹**）：
① **全程可感知**：t=0.25 走 78%、t=0.5 走 95% —— 运动均匀铺开在整段时间里，
而不是"前 1/4 时间冲完、剩下空转"；
② **平滑收尾**：末段减速收敛到 1，没有越过目标再弹回。
⇒ 曲线取 `cubic-bezier(0.32, 0.72, 0, 1)`（弹簧临界阻尼的常用近似，
与 Apple 自家浮层观感一致）。
实测（定格 · 弹窗 300ms）：0ms scale .94 → 60ms .979 → 120ms .995 → 300ms 1.000，
全程单调趋近、**无过冲**（过冲峰值 0.0%）。
⚠️ 由 tests/motion-system.test.js 静态锁住"本曲线必须无过冲"，想用过冲请显式引用
`--motion-ease` / `--motion-ease-pop`。 */
--motion-ease-sheet: cubic-bezier(0.32, 0.72, 0, 1);
/* 进场位移量。12px（C 档）：配合"快起"曲线，进场有明确的"从下长出来"。
⚠️ 真机实测（页面区块 translateY 逐帧）：12 → 6.28 → 2.06 → **-1.48** → 0
—— 落位时越过终点 1.5px 再收回，肉眼读作"落定"，不晃。
⚠️ 别再加大：超过 16px 在表格式密集页面会读成"整页在跳"。 */
--motion-rise: 12px;
/* 按压缩放。0.96 = 缩小 4%。
⚠️ 原型里的 C 档写的是 0.955 —— 定稿时**收到 0.96**：0.955 离"按钮在躲你的手指"
那条线（0.95）只差 0.005，在"C 档已经很快"的前提下再加深度按压，
会从"有咬合感"滑向"廉价"（按压深度与时长无关，不该跟着档位一起激进）。
⚠️ 到 0.95 就是廉价感的来源，别试探那条线。 */
--motion-press: 0.96;
/* 列表 / 卡片逐块进场的错峰间隔。30~40ms 是人眼能读出"依次"的最小差。
⚠️ 原型里的 C 档写的是 26ms —— 定稿时**回到 30ms**：低于 30ms 就退化成
"一起出现"，错峰的意义消失（错峰是"灵动"里最省力的一笔，不该被砍）。
⚠️ 总时长必须封顶（见 base.css 里用 `:nth-child(-n+6)` 限帽），
否则 20 行的表会跑到 600ms，用户等数据时反而觉得慢。 */
--motion-stagger: 30ms;
/* 图标（Lucide 内联 SVG，三档尺寸，stroke-width 2） */
--icon-size-sm: 16px;
--icon-size-md: 20px;
--icon-size-lg: 24px;
--icon-stroke-width: 2;
/* 布局 */
--container-max: 1440px;
/* ⭐⭐ 2026-09-28 16:55 乐哥**再次拍板**：回到 **1120**。
────────────────────────────────────────────────────────────────────────
原话：「新建排期里的二级页面，我们需要是**之前的宽度**，不是现在的。」
+「上面白色底的标题行，宽度得做得跟二级页面的宽度一样。**你做错了**」
⛔ 我做错在**方向**：
15:03 把本令牌 1120→1280、窄档 1144→1360 后，**内层还有 4 处硬编码 1120**
在生效 ⇒ 实际内容列仍是 **1120**，而**白色标题行 `.detail-head` 是撑满
`.page--narrow` 内容区的 1280** ⇒ 那段时间是「标题行 1280 / 内容卡 1120」，
左右各差 80px、明显不齐。
16:06 我修的时候，选择**把内容卡改宽到 1280 去凑标题行** —— 把不齐抹平了，
但代价是**内容整体变宽 160px**。乐哥要的是**反方向**：
**内容保持 1120，把标题行收到 1120 跟它对齐。**
⚠️⚠️ 与 `layout.css` 的 `.page--narrow` 是**两个来源取小**的关系 ⇒ **必须同值**。
本处 1280→**1120**，窄档 1360→**1200**（1200 − 左右 padding 各 40 = 内容 1120）。
两源同值后：`.detail-head` / `.sf-hero-line` / `.sf-tabs__inner` /
`.sf-body__content` / 内容卡 **全部 1120、左缘对齐成一条竖线**（一处改齐全部）。
⚠️ 为什么改窄档而不是给标题行单独加 max-width：单独加会让「1360 的页容器里
飘着 1120 的标题行」，左右还要各自居中一次、极易错位；改档位是**唯一宽度来源**，
符合本项目的"两档制"（不自造第三档）。 */
/* ⭐⭐ 2026-10-06 全站缩放系数（乐哥提「页面 dpi 有点大，想整体调小」）
──────────────────────────────────────────────────────────────────────
▸ 根因（真机实测，不是猜）：他的 Mac + 4K 显示器，**系统缩放设成 1920×1080 等效**
⇒ dpr = 2。同一块 4K 屏上，元素物理尺寸是 Win 4K@100%（dpr 1）的**整整 2 倍**：
正文物理 28px vs 14px / 表格行高 134px vs 67px / 侧栏 480px vs 240px。
他「浏览器要缩到 80~90% 才舒服」= 在手动把这 2 倍拉回来。
⇒ 修法 = 在「被系统放大过」的设备上把整页缩回去（应用规则见 base.css）。
⛔ **不能用"改字号令牌"代替**：`var(--font-size-*)` 840 处，但 `height: Npx` 硬编码
316 处 vs `--control-height*` 仅 49 处、全站 px 共 4278 处 ⇒ 只改字会变成
"字小了、按钮/行高没小"，必然错位。整页缩放**只能靠 zoom**。
⛔ **不能无条件全局缩**：Win 4K@100%（dpr 1）正文物理已是 14px，再 ×0.85 ⇒
11.9px **过小**（把本来正常的人弄坏）。⇒ 必须 dpr 感知。
▸ 应用条件：`@media (min-resolution: 1.5dppx) and (min-width: 1600px)`（见 base.css）。
命中 = Mac 4K@1920等效 / Mac 5K / MacBook Retina(≥1600) / Win 4K@150%+；
不命中 = **Win 4K@100%** / Win 1080p / MacBook 13"(1440) / 手机。 */
--app-scale: 0.85;
/* ⭐⭐ 2026-10-06：1120 → **1330**（= .page--narrow 的 1410 − 左右 padding 各 40）
⛔ 为什么必须跟着放大：`zoom` 会**连宽度上限一起缩** —— `.page--narrow` 的 1200
是逻辑值，缩完只剩视觉 **1020** ⇒ 表单页比原来**窄 15%**。
补救 = 宽度上限 **÷ 0.85 等比补偿**（1200 ÷ 0.85 ≈ 1410），
使**视觉宽度与缩放前一致** ⇒ 达成"**字变小、页面占位不变**"。
⚠️ 与 `.page--narrow` 仍是"两源取小、必须同值"（门禁 ④c 锁住）。
（原注释：乐哥 2026-09-28 16:55 把 1280 收回 1120，理由是标题行要与内容卡对齐。） */
/* ⭐⭐ 2026-10-09 乐哥拍板：**1330 → 1040**（视觉 1120 → **884**）。
────────────────────────────────────────────────────────────────────────
他给了一张「新增达人 · 基础信息」的截图：「页面有点宽，主要是每个表格的输入框很宽，
然后两个间隔很大」。实测根因：内容列 1120、两列各 **630**，而控件限宽 **380**
⇒ 每格右侧空 250、**两控件净距 269.8** —— 而 380 这个限宽正是他 2026-09-29 亲手定的
（原话「输入框没必要那么宽，右边就不用挨这么近」，当时净距 **51~71px**）。
⇒ **不是限宽错了，是内容列变宽之后没人跟着调**。
我出三档真实渲染候选（A 现状 1120 / B 910 / **C 1040**）→ 他选 **C**，并要**整板块一起收**
（不区分"表单页/详情页"，避免同一个板块里两种宽度）。
▸ 生效范围 = **整个"壳家族"**（都读本令牌）：`.sf-shell` / `.detail-shell`（达人、公司）、
排期壳（`pages-schedule.css` 的 hero / tabs / 内容列 / 底部按钮）、报销单。
⛔ **不要顺手改 `.page--narrow`（仍是 1410）**：它是 `app.js` 按"二级页档位"给
**所有**非表格二级页挂的，一刀切会把全站二级页都收窄。
壳页的档位由 `layout.css` 里一条 `:has()` 规则单独收 —— 那条必须留着，
否则**页头标题行**（撑满档位、自己没有 max-width）会比壳宽一大截。
⚠️ 门禁 `page-width-tiers ④c` 已按新关系改写（本条与 `.page--narrow` **刻意不再同值**）。 */
--form-max-width: 1040px;
/* ⭐⭐ 2026-10-06（乐哥：「侧栏和当前风格不协调」）**240 → 视觉 240**
────────────────────────────────────────────────────────────────────────
▸ 根因（量化，不是"看着窄"）：240 是**逻辑值**，而高密度宽屏会命中 base.css 的
`@media (min-resolution:1.5dppx) and (min-width:1600px){ body{ zoom:var(--app-scale) } }`
⇒ 240 × 0.85 = **视觉仅 204px**；而内容区因"视口逻辑宽被放大"反而更宽
⇒ **两侧比例失衡**，这就是"不协调"的来源。
▸ 为什么要补偿：zoom 会把宽度**一起缩**。要"视觉回到缩放前的 240"，逻辑宽必须
÷ --app-scale。本项目 `--form-max-width`(1330≈1120÷0.85)、`.page`(1900≈1615÷0.85)
已是同一套补偿逻辑。
⛔⛔ **补偿只在 zoom 生效的媒体查询里开**（见下方 `--sidebar-width-scaled`）：
无条件补偿会让 **1440 普通屏 / Win 1080p / 手机**（这些设备不缩放、也不该变宽）
侧栏凭空变成 282px —— 这是把"修高密度屏"变成"弄坏所有屏"。
⛔ 侧栏**内部竖向基线 62**（容器 padding 12 ＋ 项 padding 22 ＋ 图标 16 ＋ gap 12）、
一级 44 / 二级 40 / 分组 30 一律不动 —— 改任一项要整串重算（见 DESIGN-SPEC §8.8）。 */
--sidebar-width: 224px; /* 未缩放屏（1440 / 1080p / 手机）：原设计稿 240 −16
⭐ 2026-10-08 22:0x（乐哥：「左边菜单栏我让你适当缩小一点点」）——
240 → **224**（视觉窄 16px，约 6.7%，"一点点"档）。只动这一个令牌：
`.sidebar` 的 `width` 与 `.app-main` 的 `margin-left` 都读它 ⇒ 五板块一次生效。
⛔ 侧栏内部竖向基线（62 / 一级 44 / 二级 40 / 分组 30）一律不动 —— 这是**横向**收窄。
▸ 想再窄/回退：改这一处即可（232 = 只收 8px，208 = 收 32px，240 = 原样）。 */
/* 被系统放大过的设备：zoom 0.85 会把侧栏一起缩到 204 ⇒ 除回来补偿（240 ÷ 0.85 ≈ 282）。
⛔ 这个令牌只在 zoom 生效的同一媒体查询里被引用（见文件末尾 + base.css 同条件）。 */
--sidebar-width-scaled: calc(224px / var(--app-scale));
--sidebar-width-icon: 64px;
--sidebar-offset: 14px;
/* ⭐⭐⭐ 2026-10-07「被侧栏悬浮包裹」（乐哥选W3 档）
────────────────────────────────────────────────────────────────────────
▸ 诉求（乐哥原话）：「侧边栏上下可以做一点**入侵的圆角**，这样就有一点包裹住的感觉了，
同理内容页最右边也是」⇒ 要的是"侧栏与内容区各自成岛、中间有缝"的包裹感。
▸ 为什么需要**新令牌**：要让缝真的出现，必须**同时**改三处，它们必须同值——
· `.sidebar` 的 `top/left/bottom`（内缩）
· `.sidebar` 的 `width` = `var(--sidebar-width) − inset`
⚠️⚠️ **为什么必须改 width**（实测连栽两回，这是根因）：
① 只给侧栏 `left:inset` ⇒ 右缘 240→240+inset，而内容区
`margin-left: calc(var(--sidebar-width) + inset)` 里令牌仍是 240
⇒ 内容左缘也 240+inset ⇒ **缝永远是 0**（两栏同步平移）。
② 改用 `right: calc(var(--sidebar-width) + inset)` 也**不生效** ——
本元素写着 `width: var(--sidebar-width)`，而 fixed 元素同时有
`left + right + width` 时**CSS 规定 width 胜出**（left/right 被
over-constrained 忽略）⇒ 写的 right 直接被丢掉。
✅ 只有显式改 `width` 才真的出现缝。
· `.app-main` / `.page-tabs-bar` 的 `margin-left` / `left`
三处各写一遍数值的话，改一处就会"看起来没生效"。⇒ 抽成令牌。
▸ 为什么是 **8px**（W3 档，乐哥 2026-10-07 10:47 选）：
· W2 是 14px（= frame-gap）—— 真机看下来侧栏会变成一张**独立浮岛**，
和内容区之间的关系反而更散；
· W3 用 8px 缝 + 10px 圆角，包裹感同样成立，但内容区只少 22px
（达人列表那个最宽的表格在 1900 上限下富余 100+px，不受影响）。
⚠️ 这个值与 `--frame-gap`(14px) **故意不同**：frame-gap 是"内容白卡离视口边的缝"，
它管的是右/下两边；inset 管的是"侧栏四周离视口 + 侧栏与内容区之间"，
两者是不同的缝，不要混用。 */
--shell-inset: 8px;
/* ⭐⭐⭐ 2026-10-07「zoom 下 100vh 不含缩放」—— 边框上下不对称的真凶
────────────────────────────────────────────────────────────────────────────────
乐哥报障（14:10）：「下面怎么留白这么多，和上面顶栏的间距完全不一样」。
实测（1873×942 dpr2 ⇒ 命中 zoom 0.85）：
· `.app-main` 的 `height: calc(100vh − 2×inset)` 里 **100vh 是未缩放的逻辑视口高 942**；
· 而 body 有 `zoom: 0.85` ⇒ **框整体被缩 0.85**（942×0.85 ≈ 800）；
· 于是框比视口矮了 942 − 800 = **142px** ⇒ 下缝多出 148、上缝只有 7。
· 真机逐值：上缝 7 / 下缝 148 / 框高 787（应为 942−14 = 928）。
⚠️ 这是 `zoom` 的固有行为：**`vh` 单位不跟随 zoom，只有元素盒缩放** ⇒
任何"框 = 100vh − 常数"的高度在 zoom 下都会偏小，偏小量 = 常数 × (1 − scale) + vh×(1−scale)。
✅ 修法：把 100vh **除以缩放**，让缩放后的视觉高正好等于视口高。
⛔ 不能写成 `height: calc(100vh / var(--app-scale) - 2*inset)` 到处重复 ——
这里抽成令牌，**未缩放屏保持 100vh 不变**（普通 1440/1080p/手机不缩放）。
⚠️ 配套：`.app-shell { height: 100vh }` 同样要改（它约束着框的上边界），
见 base.css 里同条件媒体查询中的覆盖。 */
--shell-vh: 100vh;
/* 壳层圆角：侧栏右下 + 内容区四角（同一档，保持"包裹"的圆角语言统一） */
--shell-inset-radius: 10px;
/* ⭐⭐⭐ 2026-10-07 A2 档：侧栏底色加到乐哥参考图那一档。
▸ 取值依据（**从参考图逐像素取的**，不是印象）：
参考图（企业微信）侧栏灰度 **235** / 内容卡 **251** ⇒ 色阶差 **16**；
我们改造前是 248 / 255 ⇒ 色阶差仅 **7** ⇒ 侧栏偏淡、两边读成"同一块"。
取 **#EBEDF0**（灰度 237，色阶差 ≈16）落在两者之间偏 Apple 那一档，
又比参考图的 235 稍亮一档 —— 我们的内容卡是纯白 #FFF，比参考图的 251 更亮，
底色若照抄 235 会显得"脏"。
⚠️ 必须走令牌：全站禁裸 hex（`no-raw-hex` 门禁会红），改这里一处即可。 */
/* ⭐⭐⭐ 2026-10-07 15:20 **#EBEDF0 → #E3EEFB**（乐哥：「整个底栏的颜色…感觉当前这个不搭
（好像太淡了）」，随后明确方向：「**蓝色，清新点的那种**」）
────────────────────────────────────────────────────────────────────────────────
▸ 改前的两个问题（实测依据，不是凭感觉）：
① 旧值 #EBEDF0(235,237,240) 是**中性灰**（三通道几乎相等、饱和度仅 4%）
⇒ 与白色内容屏只差 **20 阶**明度 ⇒ 侧栏读成「另一块灰板」而不是「底色」；
② 无色相倾向 ⇒ 与项目主色（钴蓝 #0064E0）零呼应 ⇒ 这就是乐哥说的「不搭」。
▸ 新值 #E3EEFB(227,238,251)：**低饱和蓝**、色相 213°、蓝-红差 +22、饱和度 16%
⇒ 有明确的清新蓝倾向，又不像 #DCE9F9 那样蓝得发沉。
⚠️⛔ **必须与 `--color-content-bg` 同值**（本文件下方那条写的是**字面值**）
—— 它就是「底色包住内容屏」那四缝露出的颜色；不同色 ⇒ 侧栏与缝隙读成
两块东西，10-07 中午刚立起来的「显示屏浮在底色上」结构直接失效。
⛔ 别把 content-bg 改成 `var(--color-sidebar-bg)`：门禁 `frame-flush ④` 要按
**字面值**比对「底色 == 侧栏色」，写成引用会让那条判据解析不到值 ⇒ 静默失效。
⭐⭐⭐ **2026-10-07 21:35 #E3EEFB → #E8EEF8**（乐哥 21:27：「侧边栏那个颜色，
感觉还是深了，要再淡一点点」；21:35 拍板「就按你说的那个上」）
────────────────────────────────────────────────────────────────
▸ **方向 = 降饱和度，不是提明度**（这是本批最关键的判断）：
他说「深」，有两种可能的解法，混在一起就会走错：
· **降饱和度**（明度不变、只减蓝味）→ 蓝味变轻、观感"轻"，但
**白内容屏浮起的高度完全不变** ⇒ 不会破坏 10-07 立的包裹结构；
· **提明度**（往白靠）→ 更亮，但白屏与底色的差值被压缩 ⇒ 屏幕"糊"，
正是 15:20 他说「太淡了」的同一个病。
⇒ 选降饱和度：明度差 28 → 23 阶，仍在门禁区间内（22~36）。
▸ **被否掉的候选（留档，防后人重犯）**：
`#E9EEF6`（降饱和的更轻一档）—— 蓝-红差只剩 **13**，低于门禁下限 15
⇒ 退回 15:20 那次「不搭」的病根（中性灰、无色相倾向、看不出是蓝）。
⇒ **降饱和有下限，不能越过门禁的蓝-红差 15**。
`#EAF2FC`（当初 5 档里最淡的第 1 档）—— 明度差仅 **14**，同样低于下限 22
⇒ 白内容屏会糊在底色上，**不建议**，要上必须同时改门禁判据方向。
▸ 新值 **#E8EEF8**(232,238,248)：蓝-红差 **16**（≥15 ✅）、与白屏明度差 **23**
（22~36 ✅）、色相仍是蓝调 ⇒ 比 #E3EEFB 轻，但**仍然是"底色"不是"白板"**。
⚠️ 同批 `--color-content-bg` 也必须改（见下方那条注释）——
**两处必须同值**，否则侧栏与四缝读成两块东西。 */
--color-sidebar-bg: #E8EEF8;
/* ⭐ 2026-10-10 新增：**侧栏二级菜单引导线**的颜色（乐哥：「菜单栏是不是可以参考这个增加引导线」）
────────────────────────────────────────────────────────────────────────────
▸ 为什么**不复用** `--color-gray-300`(#DDDDDD) / `--color-gray-400`(#C6C6C6)：
那两档是**中性灰**（R=G=B）。侧栏底 `--color-sidebar-bg` #E8EEF8 是**蓝调**
（蓝 248 / 红 232，蓝-红差 16），中性灰压上去会读成"发暖的脏线"、与底色不同色系。
▸ 取值 **#A9B7CC**(169,183,204)：与底色**同色系**（蓝>红>绿），
在 #E8EEF8 上对比度 ≈ **1.75:1** —— 与飞书那条线（#B3B3B3 压白底，≈2.1:1）同级观感：
看得见是"一根线"，但不抢选中卡的焦点。
▸ ⛔ 别用主色蓝：视觉重量会盖过选中卡的白底，且与业务域色图标打架。
▸ 用法见 base.css 的 `.nav-subitems::before`（线在二级卡**外侧**，卡左缘与之相切）。 */
--nav-guide-line: #A9B7CC;
/* ⭐ 2026-09-25 Gashora 骨架落地新增：**浮岛缝隙**。
骨架由三块浮起白卡组成（顶栏卡 / 侧栏岛 / 内容区白大卡），它们之间、以及它们与视口边缘
之间的缝隙**必须全等** —— 否则会读成"没对齐"。
⚠️ 这是 2026-09-19「悬浮版」踩过的坑（当时左/中/右 2px、上/下 8px，差 4 倍）。
本令牌就是用来消灭那种不对等的：所有缝隙一律 var(--frame-gap)，不许各写各的数值。 */
--frame-gap: 14px;
--page-padding: var(--space-10); /* 40px 内容区**左右 + 底部**留白（"呼吸感"来源）
⚠️ 2026-09-29 由 32 改 40：2026-09-25「呼吸感」那一刀把 `.page` 的 gutter
从 32 加到 40，但**只改了 `.page` 一处实现** —— 财务/门户/系统配置/hr 四个
独立外壳板块各有自己的容器或覆盖规则，**没跟上**（实测四者留白各不相同）。
⇒ 令牌对齐实际值，所有板块统一引用它，以后调一处全站生效。
🔁🔁 2026-10-08 当天**改了又改回来**（完整记录，别再重复这个来回）
────────────────────────────────────────────────────────────────────────────
▸ 20:5x 我把它 40 → 16，依据是乐哥那句「最右边边框还是有点宽，弄的和上面一样；
左边这个也宽，再窄点」+ 澄清「我指的就是外部的那个窗口，就是淡蓝色的那个」。
⛔ **我理解错了**：他说的是**蓝框外侧那圈淡蓝色带**（`.app-shell` 与视口之间的
那圈）的宽度，**不是**内容卡到蓝框的内侧留白。于是我把内容页的左右留白
压到 16 —— 而真正该修的两个成因（框**内**的滚动条槽 / 框**外**的根节点槽）
当时一个都没认出来。
▸ 22:33 乐哥：「我们里面内容页，模块距离两边的距离现在太挤了，得改成之前那样
…… 之前我说改边框，你是不是改了内容页的」⇒ **正是**。当场改回 **40**。
那两个真成因后来各自归位（见下方两条 ⭐ 注释）：
· 框**内**：右侧改用 `--page-padding-right`（= 本令牌 − `--frame-gutter`）
· 框**外**：撤掉根节点 `html` 上的 `scrollbar-gutter: stable`（它白占 15px）
▸ 所以现在四边是：**上 16**（`.page` 用 `--space-4`，09-28「内容区高一点点」定的）
/ **左右 40 / 下 40**（本令牌）—— 与 10-08 改动之前**逐像素一致**。
⛔⛔ 以后听到"太挤 / 那个边框太宽"，先分清他指的是哪一层，别混：
· **框外那圈蓝带** → `--shell-inset`(8) + 根节点不许有 `scrollbar-gutter`
· **框内卡片留白** → 本令牌（左右/下）与 `--space-4`（上）
混了就会像 10-08 这样"修一个、弄坏另一个"。
⚠️ 顶栏（`.page-tabs-bar`）与财务/门户/hr/项目各容器都引本令牌 ⇒ 改这一处全站生效。 */
/* ⭐⭐⭐ 2026-10-08 21:3x **抽屉的定位框** = 蓝框 `.app-main` 的**视口坐标**（四个值一套）
▸ 为什么是"视口坐标"而不是让抽屉绝对定位在蓝框内（上一版做法）：
蓝框 `.app-main` 本身是**滚动容器**（`overflow-y: auto`，乐哥 10-07 要的"框不随滑动消失"）
⇒ 挂在它里面的 `absolute` 子元素**一定跟着内容滚**。
真机复现：在抽屉内滚轮 +500 ⇒ `.app-main.scrollTop 0 → 404`、`.drawer` top 8 → -396、
标题栏整个跑出框外被裁（乐哥：「这个怎么滑动还能滑上去的？」）。
▸ `position: fixed` 的元素相对**视口**定位，任何滚动容器都带不走它；
而 `getBoundingClientRect()` 返回的**就是**视口坐标 ⇒ 直接写进 left/top/width/height
就与蓝框逐像素重合（也不用再补"滚动条那 15px"：rect 宽度是 border box，本来就含它）。
▸ 运行时由 app.js 的 `syncDrawerFrame()` **实测写入**（切页 + resize + ResizeObserver 盯蓝框）——
**不写死 px**：这四个值随窗口尺寸 / 侧栏折叠 / 缩放而变。
▸ 默认值：`left/top = 0`、`width/height = 0` ⇒ 未同步前是一个 **0×0 的不可见空壳**
（本层 `pointer-events: none`、且没有子节点时不显示）⇒ 不会闪出一个错位的抽屉。
⚠️ 必须在令牌表里**声明**：未声明的令牌会被全站门禁判红（"用到的 var 必须有定义"）；
也不许写成 `var(--x, 兜底)`（兜底会把"令牌名拼错"静默掩盖）。 */
--drawer-frame-left: 0px;
--drawer-frame-top: 0px;
--drawer-frame-width: 0px;
--drawer-frame-height: 0px;
/* ⭐⭐⭐ 2026-10-08 21:3x **内容区右侧被"滚动条保留槽"占掉的宽度**（运行时由 JS 实测写入）
▸ 病根（乐哥：「上面说蓝边那个不等宽的，现在右边还是不等宽」——上一轮我只改了留白令牌
40→16，但右边**还多出这一条**）：
蓝框 `.app-main` 是滚动容器且带 `scrollbar-gutter: stable`（10-08 为"切 tab 不左右抖"加的）
⇒ **恒定预留**一条滚动条槽。实测：`offsetWidth 1649 − clientWidth 1634 = 15`
⇒ 卡片到蓝框：**左 16 / 右 31**（`.page` 左右 padding 明明都是 16）——
右边那多出来的 15 就是这条槽。
▸ 修法：各"承载留白的容器"（`.page` / `.fin-main` / `.ptl-canvas` / 顶栏）
**右侧内边距减掉这条槽** ⇒ 视觉留白 = `padding + gutter = 16px`，与左边、与上面一致。
▸ 为什么要 JS 量而不是写死 15px：滚动条在 macOS 默认是 overlay（不占位 ⇒ 本值 0），
Windows / "始终显示滚动条" 是 classic（通常 15~17 且用户可改）；
而且**同一台机器上滚动条有无也会变**（长页有、短页无）⇒ 写死必然在某处错位。
▸ 默认 0px ⇒ 不占位的环境行为与"不减"完全相同（零回归）。 */
--frame-gutter: 0px;
/* 承载留白的容器**右侧**该用多少 = 名义留白 − 滚动条槽（见上）。
⚠️ 只减右侧：槽只在右边。左侧、底部仍用名义值 `--page-padding`。 */
--page-padding-right: calc(var(--page-padding) - var(--frame-gutter));
/* ⭐ 2026-09-25 Gashora 骨架落地：本令牌语义**变了**（不再是"与 --tabs-bar-height 同值"）：
以前 = "顶部那一行的高度"（与 --tabs-bar-height 同值，52）；
现在 = "**吸顶高度**" —— 即"贴到顶栏下沿"该用多少。给两处用：
· analytics.js 的 headerHeight()（分析页目录条算吸附位置）
· 分析页目录条 `top: var(--header-height)`
⚠️ 值 = **上缝 + 顶栏高** = `--frame-gap + --tabs-bar-height`。
⛔ 不是"上缝 + 顶栏高 + 下缝"（那是内容区顶边，124→现在 112）——
目录条要贴在**顶栏下沿**，不是内容区顶边。
⚠️ 两令牌的关系（= frame-gap + tabs-bar-height）由 tests/restruct-topbar.test.js 的 C1
静态锁住，改 --tabs-bar-height 却漏改这里会**立刻变红**。
▸ 2026-09-26：96 → 84 ⇒ 本值 110 → 98（14 + 84）。
▸ 2026-09-26：84 → 72（A6 定稿）⇒ 本值 98 → **86**（14 + 72）。 */
--header-height: 60px; /* ⭐⭐ 2026-10-06：86 → **60**（= --tabs-bar-height，**不再加 frame-gap**）。
语义仍是"吸顶高度"（analytics 目录条 / 分析页锚点用它）：
· 09-25 起顶栏是**浮起的卡**（上方有一条 frame-gap 的缝）
⇒ 吸顶高度 = 缝 + 顶栏高（最后是 86 = 14 + 72）。
· 10-06 顶栏改回**贴顶**（top:0，与内容区拼成一张卡）
⇒ 上方那条缝不存在了 ⇒ 吸顶高度 = 顶栏高。
⛔ 别再按 `frame-gap + tabs-bar-height` 算：会多出 14px，
分析页目录条会停在半空（实测会露出 14px 滚动内容）。
⚠️ 与 --tabs-bar-height 仍必须**同步改**（门禁 C1/C5 锁着关系）。 */
--section-y: var(--space-8);
--bp-md: 768px;
--bp-lg: 1024px;
--bp-xl: 1280px;
/* 层级 z-index */
--z-base: 0;
--z-dropdown: 1000;
--z-sticky: 1100;
--z-modal: 1200;
--z-toast: 1300;
/* ------------------------------------------------------------------
二、Semantic（A2）—— 语义别名，组件层引用的唯一入口
------------------------------------------------------------------ */
/* 前景 · TDesign 文字灰阶（font-gray-1/2/3/4 = 黑 90%/60%/40%/26%）
对比度（白底）：primary 17.5:1 / secondary 5.7:1 / tertiary 2.85:1
tertiary 仅供占位符与禁用态，不得用于正文。 */
--color-fg: #1C1E21; /* 主文字 */
--color-fg-2: #3F4753; /* 正文 */
/* ⚠️ 2026-09-25 UI 美化试妆：次级文字由「紫调灰」转「冷调蓝灰」并加深一档 ——
muted #5D6C7B → #546579（白底对比度 6.5:1），meta #8595A4 → #7C8DA3（3.6:1）。
理由：全站 323 + 102 处次级文字是"灰感"的最大来源；转冷调后与主色同族，
白底可读性不降反升。 */
--color-muted: #546579; /* 次级 / 副标题 */
--color-meta: #7C8DA3; /* 辅助 / 时间戳 */
/* ⚠️ 历史变量补齐（2026-09-13）：`--color-fg-3` 早年被 4 处引用但**从未定义**
（table.css 的 .kw-scope__sep、pages-influencer.css 一处、sample-distributions.js 圆点两处）。
其中 2 处没写 fallback → `color` 声明**静默失效**（继承父级色，长期无人发现）；
另 2 处写了 `var(--color-fg-3,#C7C7CC)` → 一直显示 fallback 值。
语义上它就是「第三级前景 = 辅助灰」，与 --color-meta 同级，故就地定义（而不是改 4 处调用点）——
这样 4 处同时恢复正确，也不再有"引用了不存在的变量"这一隐患。 */
--color-fg-3: #7C8DA3; /* 三级前景（兼容历史命名，等价 --color-meta；试妆同步转冷） */
--color-placeholder: #B9C1CC; /* 占位符 */
--color-disabled: #C4CBD4; /* 禁用 */
/* 表面（TDesign Gray1 / White：卡片与页面底有明确分层）
⚠️⚠️ 2026-09-25 UI 美化试妆 **v2 修正**（乐哥反馈：「背景这个我存疑，因为这样看着也不简洁清新」）：
· v1 把页面底改成 #F0F5FB（饱和度 58% 的明确蓝）——**方向错了**。
实测全屏约 40% 面积铺这块蓝 ⇒ 大面积冷色 = 沉闷；且它与白卡只差 3.7% 明度 ⇒
卡片像"贴纸浮在蓝布上"⇒ 块状感强 ⇒ 反而更不简洁。这是"用大面积带色去凑彩色占比指标"的误判。
· v2 定调：**背景要近白（几乎看不出颜色），彩色只出现在小面积元素上**。
这正是 Notion / Linear / Vercel 的做法（底色饱和度 <15%，靠"极浅底 + 弱边框 + 留白"出透气质感）。
· ⭐ 关键认识：像素指标里的「纯灰」不等于"脏"——**明亮的近白**会被算作纯灰，但它恰恰是"简洁"的来源。
真正要打的是"暗、闷、无层次"，不是"有没有色相"。故 v2 不再追求降低纯灰占比。
三色同源（同色相、等差明度），保证不出现"两种白"的脏感。 */
--color-bg: #F6F6F6; /* 页面底（⭐ 2026-09-25 Gashora 骨架落地：#F8FAFC → #F8F8F8 → **#F6F6F6**。
参考图实测底色 #F8F8F8——**中性灰白、不带蓝调**；
旧值 #F8FAFC 带一丝冷蓝，与"克制、干净"的目标气质不符。
明度几乎不变（97.3%），仅去掉色相 ⇒ 卡片仍靠阴影而非底色反差区分。
再调 #F6F6F6：参考图实测的**界面灰底**值——比 #F8F8F8 略深一档，
才能让「侧栏浮岛 / 顶栏卡 / 内容区白大卡」浮起的层次读得出来
（三块白卡之间的缝隙就是露这条灰底）。 */
/* ⭐⭐ 2026-10-06 **壳层两底色**（乐哥：「底色不能和左边菜单栏一样颜色，应该是其他颜色，
你看下之前我们底色可以不，然后整个内容页也得有点悬浮效果」）
────────────────────────────────────────────────────────────────────────────────
左 ← 这三层从外到内、每层都要能一眼分开：
· **侧栏底** `--color-app-bg` #F4F7FC（浅蓝白，带一点蓝）
· **内容区底盘** `--color-content-bg` #F0F2F5（中性灰）← 白卡就浮在它上面
· **内容白卡 / 模块卡** `--color-surface` #FFFFFF
⚠️ 为什么不用他提的 #F6F6F6：它与侧栏底的明度只差 **1 阶**（96.9% vs 96.5%），
肉眼读起来仍是"同一块"，达不到"两色分开"的目的。
#F0F2F5 是 B 端后台的经典底盘值，与侧栏底的差别在**色相**（蓝 vs 中性），
比单纯压暗更好认。
⛔ 侧栏与内容底必须**保持不同**（这条有门禁锁：`frame-flush ④`）。 */
--color-app-bg: #F4F7FC;
/* ⭐⭐ 2026-10-06 最终（乐哥：「或者底色**用之前那个接近白色的**也行，
但是**得有悬浮效果**，其他模块，也加个悬浮，会不会好点」）
⇒ 内容底盘回到 **接近白 #F6F6F6**（就是"之前那个"），
"浮起"改由 **阴影** 承担（见 `--shadow-card`），而不是靠压暗底色。
⚠️ 与侧栏底 #F4F7FC 的色距只有 6.4 —— **这条不再作为判据**：
判据从"两底色分得开"改成"**卡片靠阴影浮起**"（见 --shadow-card 的说明与门禁）。 */
--color-content-bg: #E8EEF8; /* ⭐⭐⭐ 2026-10-07「显示屏浮在底色上」
────────────────────────────────────────────────────────────────────────────────
乐哥原话：「这个内容也就是一个有圆角的显示屏，然后显示屏是在底色（**侧边栏的颜色**）
上面的，然后侧边栏是底色，他整个包着内容页」。
⇒ **底色 = 侧栏色** —— 这才是"侧边栏就是底色、底色把内容页整个包住"的字面实现。
⚠️ 这推翻了 10-06 的「近白底盘 #F6F6F6 + 卡片靠阴影浮起」：
那版把"底色"读成"内容卡下面的衬底"，而这一版乐哥指的是**侧栏那块的颜色**
（他上一轮亲手定的 #EBEDF0）。
⚠️⚠️ **这里写字面值、不写 `var(--color-sidebar-bg)`**（两条理由）：
① 两者必须**永远相等**，但**各自可独立调** —— 写引用就绑死了，
以后想单独微调底色（不动侧栏）就没法调；
② 门禁要按字面量比对"底色 == 侧栏色"，若一边是引用，正则解析不到值 ⇒ 断言失效。
⭐⭐ **2026-10-07 15:20 随侧栏一起改为 #E3EEFB**（乐哥要「清新蓝」，
原 #EBEDF0 中性灰「太淡、也不搭」）。⚠️ 两处必须同值 —— 见
`--color-sidebar-bg` 处那段注释（不同色 ⇒ 四缝露色与侧栏对不上，包裹感消失）。
⚠️ 本轮这两条同时被门禁反向注入验过（只改一处 ⇒ `frame-flush ②/④` 立刻变红）。
⭐⭐⭐ **2026-10-07 21:35 随侧栏一起 #E3EEFB → #E8EEF8**（乐哥 21:27「感觉还是深了，
要再淡一点点」；21:35 拍板按推荐值上）—— 降饱和方向，明度差 28 → 23 阶（仍 ≥22）。
⚠️⛔ **两处必须同值**（本批改了一处就要改另一处）：
本令牌**只被 `base.css:71` 的 `body` 引用一处**，它就是「四缝 + 视口外圈」露出的色。
若与侧栏不同值 ⇒ 侧栏与缝隙读成**两块东西**，
10-07 中午刚立起来的「显示屏浮在底色上」包裹结构直接失效。
⚠️ 所以**不能只改侧栏不改本条** —— 反向注入里就有这一路（「底盘≠侧栏」）。
⛔ 别再写"接近白"：#F6F6F6(246) 与 #EBEDF0(237) 只差 9 阶，
而白卡是 255 ⇒ 屏幕与底色几乎同亮，"显示屏"完全读不出来（这是 10-07 上午的病根）。 */
--color-surface: #FFFFFF; /* 卡片（纯白，始终不变） */
--color-surface-2: #F1F5F9; /* hover / 次级底 / 表头底（v1 #EEF3FA → v2 调浅）
⚠️ 表头底仍比页面底**深一档**（Δ通道 8 vs 8，但明度低 1.3%），
使表头在近白页面上仍是清晰的"标题行"——乐哥已认可表头效果，保持该层次关系。
这是全站引用最多的表面令牌（183 处，含 --table-header-bg / --input-disabled-bg）。 */
/* 边框（同色相冷调，与主色同族）
⚠️ 试妆：由中性灰 #E5E8EC/#EDEFF1 微调为蓝灰 —— 347 处引用，
整体边界从"冷灰"变"蓝灰"，与底色/主色形成同一色彩体系。 */
--color-border: #E1E8F2;
--color-border-soft: #EDF0F4; /* 卡片描边（⭐ 2026-09-25 Gashora 试妆：#E8EEF7 → #EDF0F4，
更淡且去蓝调——参考图卡片几乎看不到描边，靠柔和阴影区分） */
/* 强调（每屏可见使用 ≤ 2 处：主 CTA + 激活态） */
--color-accent: var(--color-primary-500);
--color-accent-hover: var(--color-primary-600);
--color-accent-active: var(--color-primary-700);
--color-accent-on: #FFFFFF;
--color-accent-text: var(--color-primary-500); /* 主色文字/图标（链接、激活态） */
--color-accent-border: var(--color-primary-200); /* 主色描边（2026-09-25 补：权限页 perm-chip 等此前引用不存在的令牌，一直走兜底值） */
--color-accent-bg: var(--color-primary-50);
/* 语义色（Meta 功能色：成功 / 告警 / 危险，浅底成对） */
--color-success: #31A24C;
--color-success-bg: #EAF6EF;
--color-warning: #F2A918;
--color-warning-bg: #FEF5E7;
--color-danger: #E41E3F;
--color-danger-bg: #FDE8EB;
--color-danger-soft: #FDE8EB;
--color-price: var(--color-danger); /* 价格：与危险色同源，避免多一套红 */
--color-info: #0064E0;
--color-info-bg: #EDF4FE;
--color-info-soft: #EDF4FE;
/* 语义文字色（无底色场景专用）：--color-success/--color-warning 是给「浅底+同色字」配对的，
单独当正文文字放在白底上小字可读性不足，故各深一档；仍属同色系，不引入新色相 */
--color-success-text: #1B7F3B; /* 白底上的成功文字（对比度 ≈5.0:1） */
--color-warning-text: #B25C0C; /* 白底上的警示文字（对比度 ≈4.8:1） */
/* 语义「描边 / 整行底」变体（2026-09-14 补，把散落在 pages.css 的硬编码色收进令牌）
用途：① 描边比 --color-warning 浅，边框上更柔和；② 整行警示底比 --color-warning-bg 更浅，
避免与行内内容抢视觉。--color-danger-strong / -border 同理，用于深底文字与危险描边。 */
--color-warning-border: #F2C879; /* 警示描边（如"待结算"卡片外框） */
--color-warning-bg-soft: #FFFBF0; /* 警示整行底（比 --color-warning-bg 更浅） */
--color-warning-bg-hover: #FFF6E3; /* 上者 hover */
--color-warning-accent: #E8A33D; /* 强调描边（行首色条） */
--color-danger-strong: #D93025; /* 白底危险文字（比 --color-danger 更深，对比更足） */
--color-danger-border: #F5B5AE; /* 危险描边 */
/* 统一「提示 / 警示条」规格（2026-09-14 乐哥定稿）
------------------------------------------------------------------
乐哥原话：「所有的警示提醒，应该做成（截图）这种，**不需要右边清楚的叉**，
不要做成现在提成总览里那种**白底**的」
起因：提成总览 / 达人结算 / 华大对账 的说明条原为「近白底 + 左竖线」（--color-surface-2，
几乎与卡片同色）→ 不够醒目、且与看板页的「透明底 + 左竖线」形态各不相同。
定稿形态：**浅色底 + 圆角 + 左侧图标**（TDesign Alert 形态），**不带关闭叉**。
语义色**分两档保留**（不合并）：
· 说明类（info）→ 浅蓝底 + 蓝图标
· 警示类（warn）→ 浅橙底 + 橙图标
⚠️ 不把警示类也改成蓝色：那会让"警告"失去辨识度（乐哥要的是**形态统一**，
不是把所有提示都降级成同一种语义）。
用法：各页面自有类名（.an-banner / .st-rule__inner / .st-pending-bar …）
统一引用下面这组变量，保证以后新增提示条自动同规格。 */
--notice-radius: var(--radius-md);
--notice-pad-y: var(--space-2);
--notice-pad-x: var(--space-3);
--notice-gap: var(--space-2);
--notice-bg: var(--color-info-bg);
--notice-border: var(--color-primary-100);
--notice-ico: var(--color-info);
--notice-fg: var(--color-fg-2);
--notice-warn-bg: var(--color-warning-bg);
--notice-warn-border: var(--color-warning-border);
--notice-warn-ico: var(--color-warning);
/* KPI 徽章色调（柔和色块：图标底 + 同色系深字。2026-09-14 立 —— 原先这套 5 色
在 dashboard.js 与 influencer-detail.js **各写一份**，改一处另一处不跟随；
收进令牌后成为唯一来源，JS 侧用 UI.cssVar() 读取。 */
--color-tone-blue-bg: var(--color-primary-50);
--color-tone-blue-fg: var(--color-primary-500);
--color-tone-teal-bg: #DCF3E9;
--color-tone-teal-fg: #0F6E56;
--color-tone-orange-bg: #FBEDD9;
--color-tone-orange-fg: #854F0B;
--color-tone-green-bg: #E9F3DB;
--color-tone-green-fg: #3B6D11;
--color-tone-purple-bg: #DDD9FB;
--color-tone-purple-fg: #534AB7;
/* ⭐⭐ 每笔明细卡的循环色板（2026-10-08 乐哥，**他明确授权自定义**：
「每一笔报销的框一个颜色，每一笔一个颜色…框的颜色和表头的一致，
注意不要用很艳的颜色，不同笔数的颜色你自己做一个自定义就行，固定下来，可以循环重复」）
──────────────────────────────────────────────────────────────────────────
用途：`pages.css` 的 `.eb-dt--c1..c5 .dt__hd`（提交报销页每笔明细的头部底色）。
▸ **为什么另立一组、不复用 `--color-tone-*-bg`**：那一组是 **KPI 卡的底**，
比这里需要的浓一档；而且实测拿它按 32% 混进表头灰后，
**橙色那支极差只剩 5**（等于没颜色，违背"这样就很直观了"）、
**紫色那支把明度拉低 0.065**（那一笔会比别的笔明显重，违背"和表头的一致"）。
▸ **定值口径**（逐支验算过，见下）：
· 感知明度（HSL 的 L）与 `--color-surface-2`（表头灰 #F1F5F9，L=0.9608）**差 ≤ 0.024**
⇒ "和表头一致"（看着是同一档的浅色，不会某笔特别重）。
⚠️ 度量用 **HSL 的 L，不是 WCAG 相对亮度** —— 相对亮度里绿色权重 0.7152 最高，
任何偏紫/偏蓝的浅色都会被它判成"暗一大截"（实测紫差 -0.065），
但肉眼看着明明一样亮。这是**判据选错度量**，不是颜色不好。
· RGB 极差 **12~18**（基色 8）⇒ 一眼能分出是哪一笔，又不至于艳。
▸ 色相顺序按"相邻差异最大"排：**蓝 → 青 → 橙 → 绿 → 紫**（冷暖交替，
否则相邻两支看着像同一个色）。5 支一组循环（第 6 笔回第 1 支）。 */
--color-entry-tone-1: #EAF2FC; /* 蓝 L=0.9529 Δ−0.0078 极差 18 */
--color-entry-tone-2: #E9F5F1; /* 青 L=0.9373 Δ−0.0235 极差 12 */
--color-entry-tone-3: #FAF2E9; /* 橙 L=0.9471 Δ−0.0137 极差 17 */
--color-entry-tone-4: #EEF5E9; /* 绿 L=0.9373 Δ−0.0235 极差 12 */
--color-entry-tone-5: #EFEDFC; /* 紫 L=0.9588 Δ−0.0020 极差 15 */
/* KPI 图标块（2026-09-25 Gashora 像素级试妆：参考图的彩色实心圆角方块 + 白图标）。
色值取自参考图实测（紫/橙/粉/蓝），绿补一个同明度的标准绿。
⚠️ 与 --color-tone-*-fg 是两套：tone-fg 是"浅底上的深字"（字色），本组是"实心方块"（底色）。
只用于看板 KPI 卡（pages.css 的 .kpi-card__icon--*），别挪作正文/表头色。
⭐ 2026-10-09 乐哥：「tab 的卡片颜色样式感觉不好看…你整体看下」——
实测病根**不是色相不对**（色相是当初照参考图定的，保留），而是**四色的明度/饱和度不成档**：
#6090E0（灰调、偏暗）· #34A853（高饱和）· #F2781C（很艳）· #9050D0（偏暗且艳）
⇒ 并排时像"四个来源不同的色"。现在**只做两件事**：色相一律不动，
① 明度对齐（都压到同一档 L≈0.55~0.60）② 饱和度收敛到同一区间。
外加 blue 直接锚定品牌主色 —— 它本来就是"GMV"这个头号指标的色，
用 --color-primary-500 才与全站主色同源（改前那个 #6090E0 与主色是两个蓝）。 */
--kpi-icon-blue: #0064E0; /* = --color-primary-500（品牌钴蓝） */
--kpi-icon-green: #2FA45A;
--kpi-icon-orange: #E8952B;
--kpi-icon-purple: #6E5BD8;
--kpi-icon-pink: #F03070;
/* 图表/实心块用色（2026-10-09）—— **同一语义在"图表"与"KPI 图标"里必须是同一个色**。
病根：首页柱状图与「达人业绩占比」条的 GSV 走 `--color-tone-green-fg`（#3B6D11 暗橄榄），
而 KPI 卡的 GSV 图标走 --kpi-icon-green（鲜绿）⇒ 同一屏上出现**两个"GSV 绿"**，
读的人会把它们当成不同指标。GMV 同理（图里是品牌蓝、图标是灰蓝 #6090E0）。
⚠️ 为什么不直接把 `--color-tone-green-fg` 改掉：它语义是"**浅底上的深字**"（全站多处当文字色），
换成鲜绿会让那些地方的对比度掉下来 —— 那是另一件事，不能顺手一起改。
⇒ 单独立本组，与 KPI 图标同源（引用同一批令牌，若图标色再调这里自动跟随）。 */
--color-chart-gmv: var(--kpi-icon-blue);
--color-chart-gsv: var(--kpi-icon-green);
/* ── 侧栏一级菜单图标 · 业务域色（2026-09-25 乐哥选定「业务域分色」方案）──────────
用途：给 11 个业务分组的**图标**上色，让人**靠颜色找菜单** ——
人找菜单是按业务想（"我要看钱 → 往绿色那一片找"），不是按第几个找。
⚠️ 为什么是「按业务域」而不是「每个分组一个颜色」：
6 个业务域配 6 色 ⇒ **颜色本身在说"这是哪一类活"**；11 色全彩是纯装饰、花哨无规律。
⚠️ 协调性依据：色值**优先复用既有资产**（--kpi-icon-*，已经在看板里用了 5 个），
只有「商品青」「工具灰」是新登记的，且这两个也按"中饱和中明度"对齐既有色系的彩度
（不引入酸亮色）。
⚠️ **只给图标上色、文字仍用正文灰**（.nav-group-text 不动）⇒ 彩色面积小、不抢内容。
⚠️ 上色规则在 base.css（按 [data-domain] 选择器），domain 值由 app.js 的
NAV_DOMAIN 映射集中产出（**不按中文组名选择器** —— 组名改过一次，
按中文名写 CSS 会在改名时静默失效）。 */
--nav-domain-analysis: var(--kpi-icon-blue); /* 经营数据类：经营分析 / 业绩管理 / 月度汇报 */
--nav-domain-ops: var(--kpi-icon-orange); /* 运营执行类：达人信息 / 直播排期 */
--nav-domain-goods: #0FA3A3; /* 商品类：货品与佣金（新登记，青） */
--nav-domain-finance: var(--kpi-icon-green); /* 财务钱款类：结算与对账 / 成本管理 / 单据与票据 / 付款与台账 */
--nav-domain-risk: var(--kpi-icon-pink); /* 风险异常类：售后分析 */
--nav-domain-tool: #8A94A6; /* 工具类：系统设置 / 门户（新登记，中性灰蓝 —— 刻意最不抢眼） */
--nav-domain-personal: var(--kpi-icon-purple); /* 个人类：我的 */
/* ⛔⛔ 2026-10-08 23:40 **`--nav-domain-*-a`（强调色）已删除，别再恢复**
──────────────────────────────────────────────────────────────────────────
当天走了个来回，结论记在这里，免得下次又走一遍：
· 23:26 乐哥给了三张飞书截图 +「飞书彩色图标是属于双色拼接的」
⇒ 我加了 7 个 `-a` 强调色，做成"两个颜色并排"（第一版还是飞书采样的青绿/黄，很艳）。
· 23:37 乐哥：「但是颜色不要太艳啊」⇒ 改成"主色同色系去饱和 50% + 提亮"的浅档。
· 23:40 乐哥看完直接拍板：
「要不用这版的颜色吧？这版是**统一色调**，只是不同地方透明度不一样，这个最高级好看」
⇒ **他要的不是双色，是"一个色调 + 靠透明度分层"**。
✅ 现在的做法：图标第二层 = 主色 + `fill-opacity: .38`（在 icons-solid.js 渲染时写死），
**不需要任何强调色令牌** ⇒ 所以把这 7 个 `-a` 删掉，避免留一堆没人用的死令牌
（死令牌最容易让人以为"还有双色模式"，下次又改回去）。
⇒ 想调层次深浅：改 icons-solid.js 里的 `MONO_OP`（一处，全站生效）。 */
/* 标签 / 头像缺色兜底 + 品牌色（2026-09-14 收进令牌，原先散在 ui.js 里硬编码） */
--color-tag-fallback: #A6ADBC; /* 标签未指定颜色时的兜底灰 */
/* ⭐ 2026-10-19 标签三色的默认值（正常由 JS 内联覆写：`UI.tagFg/tagBg/tagLine`）。
⚠️ 必须在这里**定义**（哪怕只是指向别的令牌）：`css-var-defined` 门禁会扫到
未定义的 `var(--x)` 并判红 —— 未定义的声明会被浏览器**整条丢弃**（静默）。
⚠️ 用 `--tag-line` 而不是在 `var()` 里写兜底：`ui-token-standards` 禁止兜底写法
（令牌拼错时会被兜底静默掩盖）。 */
--tag-line: var(--color-border);
--color-brand-starmedia: #2F6BFF; /* 星盟品牌蓝（仓库标签专用，非 TDesign 色板） */
--color-tag-location: #B45309; /* 排期日历「地点」标签（暖琥珀，刻意区别于达人/平台色） */
/* 页面水印 / 顶部横幅（watermark.js 专用；原先硬编码在 JS 里） */
--color-watermark: #7C8BA1; /* 平铺水印文字色（低透明度叠加） */
--color-watermark-strong: #64748B; /* 水印文字色（高透明度档） */
/* ── Gashora 骨架令牌（2026-09-25 落地，乐哥指定参考图）──────────────────
用途：把"顶栏浮起卡"这一套骨架用到的颜色收进令牌
（项目规范：CSS 里不许写裸 hex，一律引令牌 —— 见 tests/ui-token-standards.test.js）。
命名按"用在哪"而非"是什么色"：同一个 #F4F4F6 若以后要调，只需改这一处。
⚠️ 2026-09-27：`--color-surface-canvas`（内容区白大卡底 #FCFCFC）**已删除** ——
乐哥给了 PMS 参考图后拍板去掉那层白卡（详见 layout.css 的 .page-stack 注释）。
它是死令牌的直接原因：删掉后**不要再引用**，否则 var() 取不到值会静默失效。 */
--color-frame-border: #EBECEF; /* 模块卡的描边色（.card / .module-card）——
在页面灰底上替代阴影划界（卡片 vs 底差 9 阶 + 细边框） */
--color-topbar-field-bg: #F4F4F6; /* 顶栏搜索胶囊底色 */
--color-topbar-chip-border: #E8E8EC; /* 顶栏头像胶囊的边框 */
--color-topbar-chip-hover: #F7F7F9; /* 顶栏头像胶囊 hover 底 */
--color-banner-danger: #D43A38; /* 页面顶部红色提示条底色 */
/* 模块标题栏状态底（全局通用，2026-09-10 立）
用途：带「开启/关闭」状态开关的模块，标题栏整条底色随状态切换。
黄 = 开启（单独维护 / 偏离默认，需留意）；绿 = 关闭（跟随体系 / 默认正常态）。
用法：标题栏容器加 .is-on / .is-off → background 取 --color-head-on-bg / --color-head-off-bg，
标题文字取对应 --color-head-on-fg / --color-head-off-fg。 */
--color-head-on-bg: var(--color-warning-bg); /* 开启态标题底：浅黄 */
--color-head-on-fg: var(--color-warning-text); /* 开启态标题字：深橙 */
--color-head-off-bg: var(--color-success-bg); /* 关闭态标题底：浅绿 */
--color-head-off-fg: var(--color-success-text); /* 关闭态标题字：深绿 */
/* 图表分类色（TDesign 官方扩展色板，定性色板顺序：品牌蓝 → 天蓝 → 绿 → 黄 → 橙 → 红 → 紫 → 粉）
严禁再使用 Tailwind 默认色板。 */
--color-chart-1: #0064E0; /* 品牌蓝 */
--color-chart-2: #029CD4; /* Cyan5 */
--color-chart-3: #2BA471; /* Green5 */
--color-chart-4: #F5BA18; /* Yellow4 */
--color-chart-5: #E37318; /* Orange5 */
--color-chart-6: #D54941; /* Red6 */
--color-chart-7: #8E56DD; /* Purple6 */
--color-chart-8: #E851B3; /* Pink5 */
/* 事项类型色（TDesign 官方色板，全站统一，勿改）
2026-09-06：由 Apple iOS 系统色迁移至 TDesign 同族色 */
--color-item-arrival: #8B8B8B; /* 到达 Gray7 */
--color-item-trace: #2BA471; /* 溯源拍摄 Green5 */
--color-item-source-live: #008858; /* 溯源直播 Green6（深绿，区分溯源拍摄） */
--color-item-course: #0064E0; /* 小课堂 品牌蓝 */
--color-item-interview: #8E56DD; /* 博士访谈 Purple6 */
--color-item-live: #D54941; /* 带货直播 Red6 */
--color-item-departure: #A6A6A6; /* 离开 Gray6 */
--color-item-custom: #8B8B8B; /* 自定义事项 Gray7（统一、不显眼，与到达同灰） */
/* 事项类型浅底（TDesign 对应色阶 1-2，随主色成对维护） */
--color-item-arrival-soft: #EEEEEE; /* Gray2 */
--color-item-trace-soft: #E3F9E9; /* Green1 */
--color-item-source-live-soft: #C6F3D7; /* Green2 */
--color-item-course-soft: #EDF4FE; /* 主色浅底 */
--color-item-interview-soft: #FBF0FF; /* Purple1 */
--color-item-live-soft: #FFF0ED; /* Red1 */
--color-item-departure-soft: #F3F3F3; /* Gray1 */
--color-item-custom-soft: #EEEEEE; /* Gray2 */
/* ------------------------------------------------------------------
三、Component（B-slot / C-extension）—— 组件专用 token
------------------------------------------------------------------ */
/* 聚焦环 */
--focus-ring: 0 0 0 3px rgba(0, 100, 224, 0.22);
/* 按钮 */
--button-primary-bg: var(--color-accent);
--button-primary-fg: var(--color-accent-on);
--button-primary-hover: var(--color-accent-hover);
--button-primary-active: var(--color-accent-active);
/* 主按钮渐变（2026-09-25 UI 美化第二刀「组件层」启用）——
全站 185 处 `.btn--primary` 同时生效，是「品牌化清新」最高杠杆的一处改动。
⚠️ 三态各一档：hover 深一档、active 更深一档 —— 若某态不写，会回落成纯色造成"闪变"。
⚠️ 语义按钮不走这里：`.btn--danger`（危险）必须保持纯红，红色渐变会被读成"警示升级"。 */
--button-primary-image: var(--gradient-brand);
--button-primary-image-hover: var(--gradient-brand-hover);
--button-primary-image-active: var(--gradient-brand-active);
--button-secondary-bg: transparent;
--button-secondary-fg: var(--color-accent-text);
--button-secondary-border: var(--color-gray-400);
--button-ghost-bg: transparent;
--button-ghost-fg: var(--color-fg);
--button-danger-bg: var(--color-danger);
--button-danger-fg: #FFFFFF;
/* ⭐ 2026-09-26「软蓝按钮」：浅蓝底 + 蓝字，用于**表格行内的业务动作**
（入库 / 维护 / 确认 / 查看 等，见 table.css 的操作列统一段）。
为什么需要它：这些动作原先直接用 `.btn--primary`（主按钮同款蓝实心块），
一屏 20 行 = 20 个蓝块，比页面右上角真正的 CTA（新增 / 导出）还抢眼 ——
而它只是"这一行的次级动作"。主按钮权重要留给页面级动作。
⚠️ 三态：hover 深一档（primary-200），与 `.btn--primary` 的"hover 深一档"同规律。 */
--button-soft-bg: var(--color-primary-100);
--button-soft-bg-hover: var(--color-primary-200);
--button-soft-fg: var(--color-accent-text);
/* 输入框 */
--input-bg: var(--color-surface);
/* ⭐ 2026-09-25 UI 美化第二刀：由硬编码 `#E6E8EB`（中性灰）改为引用 `--color-border`
（蓝灰族 #E1E8F2）。原因：全站边框已统一转冷调蓝灰，输入框描边若仍是中性灰，
会在一排控件里"偏黄/偏脏"（乐哥要调的「那些框」之一）。改引用后与其它框同族，
且以后调边框色一处生效。 */
--input-border: var(--color-border);
--input-focus-border: var(--color-accent);
--input-error-border: var(--color-danger);
--input-disabled-bg: var(--color-surface-2);
--input-disabled-text: var(--color-disabled);
/* ⭐ 字段标签左内缩（2026-10-09 乐哥：「文字向右移 6px，其他不动」）
用途：表单字段的标签文字（「达人名称」「品牌名」这种）往右内缩一点点，
不再死死贴着容器左缘 —— 乐哥说"标签现在有点偏左…视觉上很奇怪"。
⚠️⚠️ 必须用 padding-left，**不许用 margin-left**：
· padding-left 只推文字，控件左缘 / 网格列宽 / 右缘全都不动 = 他要的"其他不动"；
· margin-left 会把整个字段块（含控件）一起推走，还会挤压列宽 ⇒ 控件跟着变窄。
⚠️ 全站三套字段标签都引用本令牌（components.css 的 `.field-label`、
pages-influencer.css 的 `.pg-field__label`、pages-schedule.css 的 `.sf-field-col .sf-label`）
—— 改值**只改这里一个数**，三处一起变（门禁 tests/form-unify.test.js ⑦ 锁住）。
⚠️ 「标签在左」的行内小标签（`.comm-field-label` 那种同行 label）**不适用**，
它们本来就在控件左侧、没有"贴容器左边"的问题。 */
--field-label-indent: 6px;
/* 开关：激活态轨道色。模块需换色时**只覆盖这个变量**，不要去重写 .switch 的选择器
（重写选择器会与组件默认规则同特异性、靠加载顺序生效，极易静默失效） */
--switch-active-bg: var(--color-accent);
/* 表格
⭐ 2026-09-25 Gashora 像素级试妆：表头由「冷调浅蓝底 + 品牌深蓝字」改为「白底 + 灰字」——
参考图（Gashora）的表头**没有底色**，靠底部一条细分隔线与数据区分，字是中性灰。
这推翻了同日上午「方向 A 品牌化」定的品牌蓝表头 —— 是乐哥看参考图后的新方向。
⚠️ 影响面：全站所有表格（table.css 的 .table thead th）与日历周历行
（pages-schedule.css .calendar__weekdays）共用本条，改一处全站表头同时换装。
⚠️ 表头白底后，flush 卡片（.module-card--flush 有 overflow:hidden）会把大圆角裁切干净，
不存在"表头背景顶破圆角"的问题。 */
--table-header-bg: var(--color-surface);
--table-header-fg: var(--color-fg-2);
--table-header-line: #EFEFEF; /* 表头下分隔线（Gashora 落地新增：中性浅灰，见 table.css）*/
--table-row-hover: var(--color-primary-50);
--table-row-alt: var(--color-bg); /* 隔行底色（斑马纹）：比主指标行 --color-surface-2 稍深，看得出差异但不喧宾 */
/* ⭐ 2026-09-25 Gashora 骨架落地：行分隔线由 --color-border-soft(#EDF0F4) 改为**独立中性灰**。
参考图实测的表格行线是 #F2F2F2（比卡片描边更淡）——行线是"最轻"的一级线，
不能与卡片描边同色同重，否则表格内部看着和卡片边界一样重。 */
--table-divider: #F2F2F2;
/* 徽章（状态「深字 + 浅底」成对）
⭐ 2026-09-25 UI 美化第三刀：字色改为**徽章专用的加深值**（下方注释说明），
不再直接引用 `--color-warning` / `--color-danger` ——
那两个令牌被 9 个 CSS 文件 100+ 处引用（图表、成本、财务…），
动它们会波及无关模块；而 `--badge-*-fg` **只被 `.badge--*` 使用**（已核对），
改这里 = 只影响徽章文字，是可控的最小面。
⚠️ 为什么必须加深（实测对比度，非审美偏好）：
徽章底色是一层**近白的浅色**，而 `--color-warning`(#F2A918) 与 `--color-success`(#31A24C)
自身亮度偏高 —— 亮字压在浅底上，对比度实测只有 **1.86:1**（橙）/ 3.28:1（绿），
**远低于 WCAG 正文 4.5:1**，12px 小字几乎糊成一片（这是既有问题，非本次引入）。
⇒ 取「同色相、深一档」的值，**语义不变**（未授权仍是橙色系、通过仍是绿色系），
只是让人看得清。实测：橙 5.23:1 / 绿 5.09:1 / 红 5.62:1 —— 全部达标。
⚠️ 这三条只用于**文字色**；底色（`--badge-*-bg`）保持原样不动。 */
--badge-success-fg: #0B7A55; /* 原 var(--color-success) 3.28:1 → 5.09:1 */
--badge-success-bg: var(--color-success-bg);
--badge-warning-fg: #9A5B00; /* 原 var(--color-warning) 1.86:1 → 5.23:1（提升最显著） */
--badge-warning-bg: var(--color-warning-bg);
--badge-danger-fg: #C4142F; /* 原 var(--color-danger) 4.30:1 → 5.62:1 */
--badge-danger-bg: var(--color-danger-bg);
--badge-info-fg: var(--color-info);
--badge-info-bg: var(--color-info-bg);
/* KPI 大数字（2026-09-25 UI 美化第二刀）——
诊断结论里「彩色点占比 0.5%~2.1%」「品牌蓝存在感 1%~2%」的最大单一来源就是它：
30px 的大数字此前一律 `--color-fg`（近黑），是屏幕上最大的"无彩色块"。
改为品牌蓝后，每个含 KPI 的页面都自带一处主色强调（17 个页面受益）。
⚠️ 取 primary-600 而非 500：#0457CB 在彩色柔底卡上对比度 5.57:1，
比 #0064E0 的 4.61:1 更稳（柔底卡有 5 种色调，必须按最差配对取值）。
⚠️ **利润 / 亏损类 KPI 不受本令牌影响** —— pages.css 里 `.num-pos` / `.num-neg`
有更高特异性，仍显示红/绿（语义色优先级高于品牌色，这是算钱相关，不能改）。 */
--kpi-value-fg: var(--color-primary-600);
}
/* ⭐⭐ 2026-10-06 高密度屏的**宽度补偿**（与 base.css 的 zoom 严格同条件）
──────────────────────────────────────────────────────────────────────────
▸ 为什么必须同条件：`zoom: 0.85` 只在 `(min-resolution:1.5dppx) and (min-width:1600px)`
命中。若在这里无条件补偿，**1440 笔记本 / Win 1080p / 手机**（本就不缩放）侧栏会
凭空从 240 变 282 ⇒ 把"修高密度屏"变成"弄坏所有屏"。
▸ 只改 `--sidebar-width` 一个令牌：`width`(base.css .sidebar) 与
`margin-left`(layout.css .app-main) 都读它 ⇒ 侧栏变宽、内容区自动让位，
⛔ 侧栏内部竖向基线 62 / 一级 44 / 二级 40 / 分组 30 一律不动。
⚠️ 与 `--form-max-width`(1330) / `.page`(1900) 的补偿是两回事：那两个是
**上限**、本来就该等比放大；这一条是**固定宽度**、不缩放屏必须维持 240。 */
@media (min-resolution: 1.5dppx) and (min-width: 1600px) {
:root {
--sidebar-width: var(--sidebar-width-scaled);
}
}
/* 手机端：整体字号下调约 1px，让一屏显示更多内容（团队视力均无问题） */
@media (max-width: 768px) {
:root {
--font-size-xs: 11px;
--font-size-sm: 13px;
--font-size-base: 13px;
--font-size-lg: 15px;
--font-size-xl: 18px;
--font-size-2xl: 21px;
--font-size-3xl: 26px;
--font-size-4xl: 32px;
}
}
/* 无障碍：偏好减少动效时关闭位移/缩放，仅保留透明度变化 */
@media (prefers-reduced-motion: reduce) {
*,
*::before,
*::after {
animation-duration: 0.01ms !important;
animation-iteration-count: 1 !important;
transition-duration: 0.01ms !important;
}
}
/* ==== /css/base.css ==== */
/* ==========================================================================
达播工作台 — base.css
全局 reset / 排版 / 工具类 / 布局骨架（app-shell + 侧栏）
规则：所有颜色/间距/圆角引用 design-tokens.css 变量，禁止裸 hex（#fff/#000 例外）
========================================================================== */
*,
*::before,
*::after {
box-sizing: border-box;
}
* {
margin: 0;
padding: 0;
}
html,
body {
height: 100%;
}
/* 常驻预留纵向滚动条的位置（乐哥 2026-09-18「同页面切 tab 也会向右移动然后闪一下」）
--------------------------------------------------------------------------
根因（实测）：本应用页面**变高变矮时滚动条会出现/消失**，而滚动条占 15px 宽
⇒ 内容区可用宽在 1585 ↔ 1600 之间反复跳变
⇒ 所有 `width:100%` 的容器（卡片、工具栏、右对齐的页头按钮组）**右边缘横向移动 15px**。
实测（同口径、同一次会话，只在"长页/短页"之间切换）：
不处理 ：页头按钮组右缘 1553 → 1568（**+15px**）、卡片右缘 1553 → 1568（+15px）
加上本规则后：页头按钮组右缘 1553 → 1553（**0px**）、卡片右缘 1553 → 1553（0px）
而"切 tab"恰好会改变页面高度（加载态的行数与真实数据不同）→ 所以表现为"切 tab 时向右移动"。
⚠️ 判据说明（这一条我一开始判错过，记下来避免重犯）：
第一次我量的是 `documentElement.clientWidth` 是否被预留（得到"没预留"→ 误判无效）。
但**用户看到的是元素位置**，正确判据是量"右对齐元素的 right 边界在长短页之间是否变化"。
换成后者一量，结论就反了：本规则确实消除了可见位移。
⚠️ 试过但**不行**的写法：`html{overflow-y:scroll}` —— 它把跳变从视口转移到了 body
（body 因 `overflow-x:hidden` 计算成 overflow-y:auto，也成了滚动容器）→ 仍有 11px 位移。 */
html {
/* 🔴🔴 2026-10-08 22:1x **撤销根节点上的 `scrollbar-gutter: stable`**（乐哥：
「保留224，但是右侧的蓝色边要处理和上方的一样」）
────────────────────────────────────────────────────────────────────────────────
▸ 现象（量他的截图 + 本地复现，两处对得上）：蓝框**右侧的淡蓝色带比上/下宽 12~15px**
· 他的截图：右 19 视觉px / 上 0 / 下 7（他的机器 zoom 0.85 ⇒ 8×0.85=7 ✔︎）
· 本地 dpr1：右 23 / 上 8 / 下 8（差 **+15**）
· 本地 dpr2：右 44 / 上 14 / 下 14（差 **+15**，视觉 ≈13）
▸ 根因：`scrollbar-gutter: stable` 在**根节点**上恒定预留一条 15px 槽
（实测 `body.clientWidth 1905` 而 `window.innerWidth 1920`）
⇒ 整个 `.app-shell` 只有 1905 可用宽 ⇒ 蓝框右缘被推到 1897（应 1912）
⇒ 右侧蓝带 = 15(槽) + 8(inset) = **23**，而上下都是 8。
▸ 为什么现在可以撤销：这条是 **2026-09-18** 为"同页面切 tab 时整页滚动条出现/消失 ⇒
内容右移 15px"加的。但 **2026-10-07「边框锁死」之后视口本身不再滚动**
（`html, body { overflow: hidden }`，滚动已下沉到 `.app-main`），
⇒ 根节点**永远不可能出现滚动条** ⇒ 这条预留只剩"白站 15px"的副作用。
⚠️ 真正承担"切 tab 不左右抖"的是 `.app-main` 上的同一条（layout.css，门禁 ② 锁着），
它**原样保留**，别一起删。
▸ 删掉后：右缘回到 8 = 上 = 下（本地 dpr1 实测 8 / 8 / 8），且长短页切换**仍无位移**
（`scripts/frontend-debug/verify-root-gutter-1008.js` 真机量：长短页 frame 宽度与右对齐元素右缘逐项相同）。 */
/* ⭐⭐⭐ 2026-10-07「边框锁死 · 框内滚动」：**视口本身不再滚动**。
乐哥原话：「顶栏和底栏滑动的时候会消失……上下边框也是锁死的，不会随着滑动而变」。
⇒ 滚动**下沉到 `.app-main`**（它是那台"显示屏"的内部）。
⚠️⚠️ `html, body { overflow: hidden }` 少一条就会出现**双层滚动条**
（外层 window 一条、内层 .app-main 一条），用户会以为页面有两根滚动条。
⚠️ `overflow-x: hidden` 不能少：`.app-main` 内部若出现横向溢出（宽表格），
外层会跟着横向滚 ⇒ 右边框跟着跑，边框就不"死"了。
⚠️ 为何用 `hidden` 而不是 `clip`：**这里就是要它别滚**（`clip` 虽也不滚动，
但会让程序里 `window.scrollTo` 静默无效、且不阻止橡皮筋回弹），
与 `.app-main` 那处"必须 auto"的结论相反 —— 两者目的不同，别记混。 */
overflow: hidden;
}
body {
font-family: var(--font-family-body);
font-size: var(--font-size-base);
font-weight: var(--font-weight-regular);
line-height: var(--font-line-height-body);
letter-spacing: var(--font-letter-spacing-body);
color: var(--color-fg);
/* ⭐⭐⭐ 2026-10-07「**侧栏就是底色**」（乐哥：「然后侧边栏是底色，他整个包着内容页」）
────────────────────────────────────────────────────────────────────────────────
壳层现在是**两层**（不是三层）：
· **底色** `--color-content-bg` = `#EBEDF0` = **侧栏色**（同一个值）
· **显示屏** `--color-surface` `#FFFFFF` —— 内容页，四边内缩 + 四角圆角
⇒ 侧栏与四缝、视口外圈**连成一整片底色**，把白色内容页整个包在中间。
⚠️⚠️ 别把它改回与侧栏**不同**的色（这是 10-06～10-07 上午的病根）：
两色不同时侧栏读成"另一块板"、不是底色 ⇒「底色包着内容页」根本不成立。
门禁 `frame-flush ④` 现在锁的是"底盘 == 侧栏色"，不是"接近白"。
⚠️ 也别改回 #F6F6F6：它与白卡(255) 只差 9 阶 ⇒ 白屏与底色几乎同亮，浮不起来。 */
background: var(--color-content-bg);
-webkit-font-smoothing: antialiased;
text-rendering: optimizeLegibility;
/* ⭐⭐⭐ 2026-10-07「边框锁死」：body 也**不滚动**（滚动已下沉到 `.app-main`）。
⚠️⚠️ `overflow-x: hidden` 本身已让 body 在 y 方向计算成 `auto`
（见上方 09-18 那条注释里记的踩坑）⇒ 只写 `overflow-x` **挡不住** window 滚动，
必须显式 `overflow: hidden`。
⚠️ 写成 `overflow: hidden` 会不会误伤 `.app-shell` 之外的 fixed 弹层？
不会：`position: fixed` 相对**视口**定位，只要祖先没有 transform/filter/contain，
body 的 overflow 管不到它们（弹层实测正常，见 verify 脚本的弹层检查）。 */
overflow: hidden;
}
/* ⭐⭐ 2026-10-06 高密度屏「整站等比缩放」（乐哥：「页面 dpi 有点大，想整体调小」）
──────────────────────────────────────────────────────────────────────────
▸ 只在**被系统放大过**的设备上缩（dpr ≥ 1.5 且视口 ≥ 1600）。
条件依据（令牌 --app-scale 有完整推导）：
命中 Mac 4K@1920等效(dpr2) / Mac 5K / MacBook Retina(≥1600) / Win 4K@150%+
不命中 **Win 4K@100%（dpr1）** / Win 1080p / MacBook 13"(1440) / 手机
⛔ 无条件全局缩会把 Win 4K@100% 用户的正文从物理 14px 压到 11.9px（过小）。
▸ 为什么用 body 而不是 html：`.app-shell` 等骨架都在 body 内，body 一处即全站；
且 `fixed` 顶栏/侧栏实测**跟随缩放**（缩后仍贴边、吸顶页头正常）。
▸ ⚠️ 配套纪律：**宽度上限必须同步 ÷ 0.85 等比放大**（见 layout.css 三档 +
design-tokens 的 --form-max-width），否则"字小了、页面也被压窄 15%" ——
乐哥本次实测就指出了这点：「列表是不是可以再宽一点点」。 */
@media (min-resolution: 1.5dppx) and (min-width: 1600px) {
body {
zoom: var(--app-scale);
}
/* ⭐⭐⭐ 2026-10-07：zoom 下 `100vh` **不跟随缩放**（只有元素盒缩放），
⇒ 任何"height: calc(100vh − 常数)"都会比视口矮 `视口高×(1−scale)`。
实测（1873×942 dpr2、scale 0.85）：`.app-main` 上缝 7 / **下缝 148**（乐哥报障）。
✅ 这里把 `--shell-vh` 改成 `100vh / scale`：缩放后视觉高正好 = 视口高 ⇒ 上下缝对称。
⚠️ 必须**只在本媒体查询里改**：未缩放屏（1440 / 1080p / 手机）保持 100vh，
写成 `100vh / var(--app-scale)` 无条件生效会让那些屏幕的框**超高**（0.85 倍视口）。
⚠️ 与 `--sidebar-width-scaled` 是**同一类补偿**（都是"zoom 会缩、令牌要除回来"），
改一处请同时想另一处。 */
:root {
--shell-vh: calc(100vh / var(--app-scale));
}
}
a {
color: inherit;
text-decoration: none;
}
button {
font-family: inherit;
cursor: pointer;
}
input,
select,
textarea {
font-family: inherit;
font-size: inherit;
color: inherit;
}
ul,
ol {
list-style: none;
}
img {
display: block;
max-width: 100%;
}
.hidden {
display: none !important;
}
/* 数字统一等宽：金额/数量/百分比/场次 */
.num {
font-feature-settings: "tnum", "lnum";
font-variant-numeric: tabular-nums;
text-align: right;
}
/* 价格：醒目红色 + 加粗（货品售价/达播价等） */
.price {
color: var(--color-price);
font-weight: var(--font-weight-semibold);
font-feature-settings: "tnum", "lnum";
font-variant-numeric: tabular-nums;
}
/* 页面内容切换：淡入 + 轻微上移 + **逐块错峰**
══════════════════════════════════════════════════════════════════════════
2026-09-26 动效升级（乐哥：「轻盈灵动，不要傻快傻快」）—— 两处改动：
① 曲线从 ease-standard 换成 `--motion-ease`（easeOutQuint），
位移从写死的 6px 换成令牌 `--motion-rise`；
② **加错峰**：原来 `.page` 的所有直接子级（页头 / 工具栏 / 卡片…）**同时**开始动画，
读起来是"一整块拍上来"。现在依次错开 36ms，
视线会被自然地"带着往下走" —— **错峰是"灵动"最省力也最有效的一笔**。
⚠️⚠️ 为什么延迟只给前 5 个（`:nth-child(-n+5)`）：
不封顶的话，一个 12 个子级的页面最后一个要等到 12×36 = 432ms 才开始，
用户点完菜单要盯着半空的页面等 —— 那是"慢"，不是"轻盈"。
第 6 个往后通常已在首屏之下，不参与错峰没有观感损失。
⚠️ fill-mode 用 **`backwards`**（不是 `both`！）：
· `backwards` 负责"延迟期间保持 `from` 态（透明）"——不写的话延迟期间元素是
"最终态"，会出现"先亮出来、再突然淡入"的闪烁（这是**原有诉求**，backwards 已满足）。
· ⛔ `both` 比它多的那一半 `forwards`（**结束后保留终值**）不但是多余的、
而且**有害** —— 2026-09-26 乐哥实报「点时间组件后，被上层卡片遮住了」的事故根因：
终值 `transform: translateY(0) scale(1)` 的计算值是 `matrix(1,0,0,1,0,0)`、**不是 none**，
而非 none 的 transform 会**创建层叠上下文** ⇒ 每个页面直接子级（工具栏/卡片容器…）
永久变成层叠上下文 ⇒ 里面的下拉面板 `z-index: 1000` 被锁死在容器内部，
与后面的兄弟（卡片）比较时按"容器的层级"排 ⇒ 面板被卡片盖住（实测命中 .kpi-card__value）。
改 backwards ⇒ 动画结束后元素上**无任何动画残留**（transform 计算值 = none）
⇒ 层叠上下文消失，面板恢复盖住卡片（实测面板中心命中 .mp__grid）。
· ⚠️ 别为了"必须有终值"改回 `both`/`forwards`：视觉终值 = 元素自然态，
撤掉填充不会跳变（实测采样无中间帧突变）；而层叠上下文是**静默**副作用。
· ⚠️ 也试过"`to` 帧去掉 transform"这条更隐晦的写法 —— **无效**（实测 Chrome
仍会为隐式终值生成单位矩阵 ⇒ 照样创建层叠上下文），不要采用。
⚠️ 同时只动 opacity + transform（不触发重排）。
⚠️ 只在**路由切换**时播：`.page` 由 app.js 按路由新建（见 createTabContainer），
页面内部的筛选/翻页是重绘 `.card` 内部的容器，不碰 `.page` 的直接子级
⇒ 不会每点一次筛选就整页重来（已真机核实，见 probe 的「筛选不重播」断言）。
══════════════════════════════════════════════════════════════════════════ */
.page > * {
/* ⭐ 2026-09-26：曲线由 --motion-ease 换成 --motion-ease-pop（弹入，落位轻微回弹）。
页面区块是"从无到有"的元素，没有"对准"语义 ⇒ 过冲大一点更生动。
⚠️ 不要在这里用 --motion-ease（那是**位移**曲线，过冲只有 2px 级）——
实测用它播页面进场，肉眼读不出"弹"，只显得"滑了一下"。 */
animation: page-fade-in var(--motion-page-enter) var(--motion-ease-standard) backwards;
}
.page > *:nth-child(2) { animation-delay: var(--motion-stagger); }
.page > *:nth-child(3) { animation-delay: calc(var(--motion-stagger) * 2); }
.page > *:nth-child(4) { animation-delay: calc(var(--motion-stagger) * 3); }
.page > *:nth-child(5) { animation-delay: calc(var(--motion-stagger) * 4); }
/* ══════════════════════════════════════════════════════════════════════════
⭐⭐ 2026-09-29 三个「板块外壳」页面的错峰**下沉一层**
（乐哥：「hub 首页，财务中心，还有 hr 那个系统 ui 动效，都统一下」）
──────────────────────────────────────────────────────────────────────────
🐞 现象：达播台的页面是 4~5 块依次错峰 30ms 带下来；而门户 / 财务中心 / 人事行政
**整块"拍"上来**（真机实测：这三页 `.page` 只有 **1 个**直接子级，
上面那套 `:nth-child` 错峰对它们没有任何东西可错）。
根因不是"忘了加动画"—— 是这三个板块的**外壳结构不同**：
它们各自有一个根容器（门户/财务/系统配置共用 `.fin`，人事用 `.kq-page`），
所有内容都包在里面，于是错峰被"包"住了。
✅ 做法：把错峰下沉到"外壳内的第一层"（`.fin-main > *` / `.kq-page > *`），
并**抑制根级那条**动画 —— 不抑制的话两层 transform 会叠加，
内容实际位移变成 24px（是别的页面的两倍，"跳"一下）。
⚠️⚠️ 为什么**只下沉一层**、不去更深的"卡片那一层"（那样理论上更接近达播台的观感）：
财务中心 `#fin-body` 的子级在**每次筛选 / 翻页 / 切子页时都会被
`innerHTML` 整体重建** ⇒ 在那一层挂动画 = 用户每点一次筛选就整页重播一遍，
正是本文件上方明令禁止的"每点一次筛选就整页重来"。
实测确认（空库真机）：hr 的 `#kq-body` 子级在筛选时**不**重建、财务的**会**。
⇒ 既然只有一个板块安全，就**统一取对所有板块都安全的层级**，
而不是"hr 更深、财务更浅"——那会让三个板块彼此之间又出现新的不一致。
⚠️ keyframes 复用上面的 `page-fade-in`（不新造）；⚠️ **曲线是 `--motion-ease-standard`，
⛔ 不是 `--motion-ease-pop`** —— 本条在 2026-10-11 之前误写成 "复用 --motion-ease-pop"，
与下面那行代码（standard）**不符**，把动效验收脚本的判据也带偏了（它照注释期望 1.68 过冲 ⇒ 恒红）。
依据是 §9.10 定稿（2026-10-08 乐哥：「整个页面…都是淡入淡出；页面内切 tab 才是左右滑动」）：
**页面进场只淡入、不带过冲**（过冲是"位移/弹入"的语义，淡入用它只会闪）。
⚠️ 延迟只有第 2 块（这三页只有"页头 + 内容"两块），同样走 `--motion-stagger`。
⚠️ fill-mode 必须是 `backwards`（与上面同因：`both` 会在结束后留下单位矩阵 transform
⇒ 创建层叠上下文 ⇒ 页内下拉/弹窗被卡片盖住，2026-09-26 的实际事故）。
══════════════════════════════════════════════════════════════════════════ */
.page > .fin,
.page > .kq-page {
animation: none; /* 交给下面这一层做，避免两层位移叠加 */
}
.fin-main > *,
.kq-page > * {
animation: page-fade-in var(--motion-page-enter) var(--motion-ease-standard) backwards;
}
.fin-main > *:nth-child(2),
.kq-page > *:nth-child(2) {
animation-delay: var(--motion-stagger);
}
/* ⭐⭐⭐ 2026-10-08 00:5x 页面进场改为 **Apple 官网式渐显**
* ────────────────────────────────────────────────────────────────────────────────
* 乐哥：「页面切换…我们应该做 apple 官网那种渐变显示」。
*
* ⛔⛔ **改前实测（真机，非印象）**：
* animation: page-fade-in 155ms cubic-bezier(0.34, 1.68, 0.5, 1) backwards
* → 时长 155ms / 位移 12px / scale 0.985 / **曲线 pop（过冲 68%）**
*
* ▸ 为什么"155ms + pop"读作"弹一下"而不是 Apple 的"浮现"（Apple 官网的观感拆解）：
* Apple 的产品页切换是三件事叠加，缺一不可：
* ① **时长够长**：约 400~600ms，让内容有时间"浮现"；
* 155ms 在这个尺度上太快 ⇒ 人眼只抓到"中间那一瞬" ⇒ 像闪。
* ② **曲线**：`--motion-ease-pop` = (0.34, **1.68**, 0.5, 1)，
* y1=1.68 ⇒ **过冲 68%** ⇒ 内容会冲过终点再回来 ⇒ 这正是"弹"的来源，
* 与 Apple 的"缓缓落定"正好相反。Apple 用的是**平滑减速**（无过冲）。
* ③ **位移 + 透明度配比**：位移小、透明度变化为主 ⇒ 读作"浮现"；
* 本项目是位移 12px 为主 ⇒ 读作"从下滑入"。
* ⇒ 三条一起改，不是只把时长拉长。
*
* ✅ 改法（各自有据）：
* 时长 155 → **420ms**（落在 Apple 的 400~600 区间下沿，取保守值：
* 再慢会让"点菜单→看到内容"的等待感变明显，420 是"明显是渐变"与"不覺得慢"的平衡）
* 曲线 pop → **--motion-ease-standard**（= easeOutQuint，**无过冲**，平滑减速）
* 位移 12 → **8px**（更小；Apple 位移克制，主角是透明度）
* scale 0.985 → **0.995**（幅度几乎取消；0.985 在420ms 下会读作"内容在长大"）
* ⛔ **错峰 delay 取消**：错峰原本配155ms+30ms 步长成立（每块 30ms 差得开）；
* 时长拉到 420ms 后，30ms 的错峰在时长里占比变小 ⇒ 观感是"一起动"，错峰失效。
* ⚠️ 但**不能直接删 nth-child 那几条**（那是给 5 块内容分别设的）：
* 保留它们无害（delay 30~120ms 仍在420ms 窗口内，Apple 也有轻微错峰）。
* ⇒ 保留不动，只改时长/曲线/位移/缩放四项。
* ⚠️⚠️ **为什么时长必须走令牌、不能写死 420ms**：
* 本文件下面还有 4 处 `page-fade-in`（`.fin-main > *`、`.kq-page > *` 等板块外壳），
* 它们各自带不同 delay。若这里写死 420 而那些地方仍走 `--motion-base`(155)，
* ⇒ **同一套动效语言在四个板块里速度不一致**（今晚已在CSS 里栽过同类坑）。
* ⇒ 新增 `--motion-page-enter`，一处改全站跟随。 */
@keyframes page-fade-in {
/* 从"下方一点点 + 极淡"浮现：位移与缩放都收到最小，主角交给 opacity。
曲线用 ease（平滑减速、无过冲）—— 这是与旧版最大的差别。 */
from { opacity: 0; transform: translateY(8px) scale(0.995); }
to { opacity: 1; transform: translateY(0) scale(1); }
}
/* 编号/订单号/SKU/佣金编码等宽 */
.mono {
font-family: var(--font-family-mono);
}
/* 超长文本截断 */
.ellipsis {
overflow: hidden;
text-overflow: ellipsis;
white-space: nowrap;
}
/* ============================ 布局骨架 ============================ */
.app-shell {
display: flex;
/* ⭐⭐⭐ 2026-10-07「边框锁死 · 框内滚动」：`min-height` → `height`。
▸ 为什么必须换：内容超高时 `min-height:100vh` 会让本容器**被内容撑高**，
而 `.app-main` 的兄弟关系决定它要按容器高度算边框 —— 容器一高，
底部那条缝就被推到视口外，"底边框锁死"直接失效（实测框高会 = 内容高）。
▸ `height: var(--shell-vh)` + `overflow: hidden` ⇒ 容器恒等于一屏，超出部分由 `.app-main` 自己滚。
⚠️ 用 **`var(--shell-vh)`** 而不是 `100vh`：zoom 环境下 `100vh` 不含缩放
（乐哥 14:10 报「下面留白这么多」的真凶，实测上缝 7 / 下缝 148）。
未缩放屏该令牌 = 100vh，行为不变。 */
height: var(--shell-vh);
/* ⚠️ 移动端那侧 `.app-shell` 另有 `height: 100dvh` 的处理，别被这条覆盖掉
（见 layout.css 移动端段落）。 */
overflow: hidden;
}
/* ---- 侧栏（白色，与顶栏/标签栏同色；右侧一条 1px 线与内容区分离）----
2026-09-19 晚：乐哥拍板**取消「整体悬浮」**，改为「方案A：贴边」。
前一版是「侧栏与内容列各是一块 14px 圆角面板、彼此留 2~8px 缝浮在桌面色上」，
实测两个毛病（都写进了技能 `dabotai-ui-consistency-fix`）：
① 缝宽不对等：左/中/右 2px、上/下 8px（差 4 倍）→ 读起来像"没对齐"而非"刻意留白"
② **滚动后两块面板顶边错开 8px** —— 本元素是 fixed（视口 top=8），
而内容列的 margin-top:8px 是**文档坐标**、随文档滚走 →
内容顶边落到视口 0、本元素顶边仍在视口 8。只测"未滚动"的探针永远发现不了。
⇒ 现在 top/left/bottom = 0（贴边通高）、直角、无阴影，靠 border-right 一条线分离。
⚠️ 这三条必须与 .app-main 的 margin 配套；移动端（抽屉式）在 layout.css 的
@media (max-width:768px) 里另有覆盖，不依赖这三个值。 */
.sidebar {
/* ⭐⭐ 2026-09-25 Gashora 骨架落地：侧栏从「贴边通高 + 右边一条线」改为**浮起的圆角岛**。
参考图（乐哥指定）：左侧菜单栏是独立的一个岛，四周有缝、露出灰底。
▸ top 0 → **calc(frame-gap + tabs-bar-height + frame-gap) = 112px**（值随令牌走，此处只是当前读数）
（顶栏 fixed 占据最顶部，侧栏从它下方开始）。
▸ left / bottom = --frame-gap：与顶栏的四周留白**同值**（缝宽对等，不许各写各的）。
▸ 圆角 18 + 柔和阴影：从"一块贴边区域"变成"一张浮起的卡"。
▸ 去掉 `border-right`（那条 #E5E8EC 竖线是"贴边"形态的分界，岛形态靠缝隙+阴影分界）。 */
position: fixed;
/* ⭐⭐ 2026-10-06 **侧栏改成"不悬浮"（贴边平面）** —— 乐哥：
「我其实是觉得顶栏不是悬浮了，侧边菜单栏是不是也按照不悬浮的样子做」。
▸ 三边贴 0、圆角 0、无边框、无阴影 —— 与顶栏（09-28 起就是贴边贯穿）**同一套形态**。
▸ 底色 = **transparent**（与页面底盘 --color-bg 同色）—— 乐哥要"不要底"，
侧栏与内容区之间的分界改由**右侧一条 1px 细线**承担（与顶栏的底部细线同一套语言，
两线在左上角交汇）。⛔ 不要给它实色底：那会退回"侧栏是一块面板"的旧形态。
▸ 顶栏竖高 60px，侧栏从 0 起 ⇒ 侧栏的品牌区（同高 60）与顶栏**天然共线**。
⚠️⚠️ 保留下来的两条**不能删**：
· `overflow: hidden` —— `overscroll-behavior: contain` 只对"滚动容器"生效，
改 visible 会让"侧栏滚轮带动页面滚动"那个 bug **静默复发**（tests/restruct-topbar.test.js F2 锁着）。
· `z-index: var(--z-sticky)` —— 侧栏要压在 `.app-main` 之下/之上关系稳定。
⚠️ 与 frame-flush 门禁的关系：旧断言锁的是"浮岛几何"（top 公式 / 四边缝 / 圆角 18）。
本次是**方向反转**（09-19 贴边 → 09-25 浮岛 → 现在回到贴边），
断言已同步改成"贴边平面"那一组，别再照旧断言改回去。 */
/* ⭐⭐⭐ 2026-10-07 **方向反转**：贴边 → **内缩成浮岛**（乐哥选 W3 档）
────────────────────────────────────────────────────────────────────────────
乐哥原话：「侧边栏上下，是不是可以做一点**入侵的圆角**，这样就有一点包裹住的感觉了，
同理内容页最右边也是」+ 底色「你看要不要和参考图一样重一点」。
⇒ 从「三边贴 0、直角、无底色边界」改为「四周内缩 `--shell-inset`、右下圆角、实色底」。
▸ 几何实测依据（1920×950，改造前）：
侧栏 → 内容区缝隙 = **0px（贴死）**；侧栏与内容区上缘都贴视口顶（y=0）
⇒ 贴死时**根本没有"包裹"可言**，而上缘贴边**给不了上圆角**
（会在视口角露出 body 底色，像"缺了一块"）
⇒ **入侵圆角只能落在下方两角**（侧栏右下 / 内容区左下）。
▸ ⚠️⚠️ `width` 必须显式减（这条是本改动的关键，实测连栽两回）：
只给 `left: inset` ⇒ 侧栏右缘与内容区左缘**同步平移** ⇒ 缝永远是 0；
改用 `right:` 也不行 —— 本元素写着 `width`，而 fixed 同时有
`left+right+width` 时 **width 胜出**（left/right 被 over-constrained 忽略）。
⇒ `width: calc(var(--sidebar-width) - var(--shell-inset))` 缝才真的出现。
▸ 底色 #EBEDF0（乐哥 A2 档）：与内容白卡的色阶差 ≈16，对齐他给的参考图
（实测参考图侧栏灰度 235 / 内容卡 251；我们改造前是 248 / 255 = 仅 7 阶）。
⚠️ 折叠态 `.is-collapsed .sidebar { width: var(--sidebar-width-icon) }`
覆盖本条 width ⇒ 折叠时缝隙会变成 inset + (icon − full)，见 layout.css 那处的补偿。
⚠️ 移动端（≤768px）侧栏是抽屉（overlay 定位、不占 flex 宽）⇒ 本条内缩对它无意义，
见 layout.css 移动端段落的复位。 */
/* ⭐⭐⭐ 2026-10-07 **第二次方向反转**：浮岛 → **底色本体**（乐哥：
「侧边栏是底色，他整个包着内容页」）
────────────────────────────────────────────────────────────────────────────
▸ 关键认知（这一版才真正读懂他的意思）：
上一版把侧栏做成「内缩的浮岛」，但**浮岛和底色是两块东西** ——
岛有岛自己的边界，于是"包住"读不出来。
他要的是：**侧栏 = 底色本身**（贴边、通高、无边界），
内容页 = 一块**有圆角的显示屏**，浮在这片底色上。
⇒ 侧栏一旦变成底色，它就**不能有圆角、不能内缩**（有边界就不是底色了）。
▸ 因此侧栏恢复 `top/left/bottom: 0`、`width: var(--sidebar-width)`、无圆角。
包裹感改由**内容页那侧的四条缝 + 四角圆角**承担（见 layout.css 的 `.app-main`）。
▸ 底色一致性：`--color-content-bg` 现在 `= var(--color-sidebar-bg)`
（design-tokens 已改）⇒ 侧栏、四缝、视口外圈**连成同一片底色**，
内容白卡浮在正中 ⇒ 「底色包着内容页」成立。
⛔ 不要再把这两个令牌改回不同值：那会让侧栏又变成"另一块板"（10-07 上午的病根）。 */
top: 0;
left: 0;
bottom: 0;
/* ⚠️ 宽度回到 `--sidebar-width`（不再减 inset）：侧栏是底色、要贴边，
留缝会让人看到 body 的另一层色，底色就不连续了。 */
width: var(--sidebar-width);
display: flex;
flex-direction: column;
/* 底色 = 与 body 同一个令牌 ⇒ 侧栏与四缝、视口外圈融成一整片。
⛔ 不用裸 hex（全站禁裸 hex，门禁 no-raw-hex 会红）。 */
background: var(--color-sidebar-bg);
/* ⭐⭐⭐ 侧栏**不再有圆角**：它是底色，有圆角就变成"一块板"了。
内容页的圆角在 `.app-main` 上（四角），那才是"显示屏"的形状。 */
border-radius: 0;
/* ⭐ 2026-10-06 定下、2026-10-07 复核仍成立：**无边框**
（乐哥：「上一个版本侧边栏的样式挺好看」）——
侧栏与内容区的分界改由**缝隙 + 圆角 + 底色差**承担（三者都是 10-07 加的）。 */
border: none;
box-shadow: none;
overflow: hidden;
/* ★ 侧栏滚轮隔离（2026-09-19 乐哥：「鼠标在左边菜单栏，菜单栏不能滚时，
滑动滚轮右边页面跟着滚」）—— 滚轮在侧栏上滚不动/到边界时，不再链式传给页面。
**全站就这一条声明**（没有 JS、nav 上也不写），经三层对照实验定稿：
· 去掉本条 → 行为断言红 3 条（搜索入口 / 底部「我的」穿透）
· 只在本条 + 去掉 nav 条 → **行为断言全绿**（故 nav 那条已删，行为上冗余）
· 再加一段 JS preventDefault → 行为无任何差异（故 JS 也删了）
⚠️⚠️ **生效前提：本元素的 overflow 不能改成 visible** ——
`overscroll-behavior` 只对**滚动容器**生效，而本元素正是靠 `overflow:hidden`
才成为滚动容器、从而截断这条滚动链。改成 visible 会让修复**静默失效**、
乐哥那个 bug 原样复发。该前提由 tests/restruct-topbar.test.js 的 F2 静态锁住。 */
overscroll-behavior: contain;
z-index: var(--z-sticky);
transition: width var(--motion-base) var(--motion-ease-standard);
}
/* 侧栏品牌区也弱化，和菜单融为一体。
⚠️ height 用 --tabs-bar-height（= 顶部那一行）而**不是** --header-height：
两者当前同值，但语义不同 —— 本元素要与标签栏那一行共线，
跟"标签栏多高"走比跟"（已撤的）顶栏多高"走更不容易错。
⭐ 2026-09-20 起它**同时是一个按钮**（点击回首页，乐哥：「然后点击也能返回首页」）：
所以这一条同时是"品牌区的样式"，也是"回首页按钮的样式"。
点击/键盘的事件绑定在 app.js 的 renderSidebar（**只绑一次**，原因见那里的注释）；
焦点环由 base.css 的全局规则 `:where(button,[role=button],[tabindex]):focus-visible` 提供。 */
.sidebar__brand {
display: flex;
align-items: center;
/* ⚠️ gap 12 → 8（2026-09-20）：侧栏固定 240px，logo 与文字**抢同一块宽度**。
文字要放到 20px（8 个汉字需 160px），可用宽 = 208 − logo36 − gap
⇒ gap 必须让出 4px 才够（12→8 后可用 164，留 4px 余量）。
⚠️ 2026-09-21 名称简化为 6 字 + 字号降到 18px 后，文字只用 108px、余量 56px
⇒ **这一条已经不卡在及格线上了**（当时的紧张关系已消失）。
保留 8px 是**为了与 --space-2 的间距节奏一致**，不是"放不下才这么写"；
别因为"现在很宽裕"就把它调大 —— 那会把菜单区整体视觉推挤。
详见下方 .brand-name__zh 的计算。 */
gap: var(--space-2);
/* ⭐⭐⭐ 2026-10-08 14:5x 高度 `--tabs-bar-height`(60) → **`--sidebar-brand-h`(92)**
────────────────────────────────────────────────────────────────────────────────
乐哥：「左边菜单栏文字的高度，按照我截图这个为标准做，就是红框线下面」
+「logo 和文字看要不要整体下移」。
▸ 关键：品牌区**下沿就是菜单起始线**（= 页头卡顶边 92，真机实测）。
留白并进品牌区后 —— ① `.sidebar__nav` 的 padding-top 归零（见那一条），
滚动容器的裁切边 = 92 ⇒ 展开很多、滚动时菜单**滑不出这条线**；
② 品牌内容 `align-items:center` ⇒ 整块顺势下移（logo 12→28，居于 92 正中），
正好回应他「整体下移」那一问。
⚠️ 品牌区高仍与顶栏那一行**共线**这条老约定**在本值下不再成立**：乐哥本次以
截图为准，明确接受 logo 下移。别再按旧注释"改回 60"。
⚠️ hover 底色的作用范围随之变成 240×92（整块品牌区可点回首页，语义成立）。 */
height: var(--sidebar-brand-h);
/* ⭐⭐ 2026-10-06 品牌区回**侧栏**（不再搬到顶栏）——
依据：参考图那条 dashboard 是「品牌在侧栏顶部、顶栏只放页面定位」；
且侧栏贴边后顶部本来有 72px 空档，品牌回来正好把它用掉。
▸ 左内边距 20：品牌名落在 x=62（= 20 + logo36 + gap6），与下面菜单文字**同一条竖线**；
logo 本身落在 20（与菜单图标的 34 差 14px，不影响读感——名字对齐更重要）。
▸ 去掉底部分隔线：侧栏与页面同底、贴边，再画一条线会显得"侧栏是一块被框住的区域"，
与"不悬浮"的整体形态相悖。 */
padding: 0 20px;
border-bottom: none;
flex-shrink: 0;
/* 可点击回首页 —— 与全站可点组件的语言保持一致（.nav-item 也是 cursor:pointer） */
cursor: pointer;
transition: background-color var(--motion-fast) var(--motion-ease-standard);
}
/* hover 反馈：让"这里能点"被发现。用 --color-surface-2（= .nav-item:hover 同款令牌），
不新造颜色；侧栏是白底，hover 到 #FAFBFC 是同一档非常轻的灰，与菜单项手感一致。 */
.sidebar__brand:hover {
background: var(--color-surface-2);
}
/* ⚠️ 焦点环要**向内收**：本元素通栏贴左右边缘（宽 240 = 侧栏宽），
全局规则那条 `outline-offset: 2px` 会把环画到侧栏外面、被 `.app-main` 裁掉一部分。
只调偏移、不改颜色与粗细，仍是同一套焦点环。 */
.sidebar__brand:focus-visible {
outline-offset: -2px;
}
/* ---- 品牌区高度 = 顶部区那一行（2026-09-19 结构重排后**只有一行**了）----
▸ 历史（两次相反的需求，别把哪一次的修法当成唯一答案）：
① 2026-09-19 上午：「左上角 logo 的高度和顶部菜单栏保持一致」→ 当时顶部**有两行**
（面包屑行 56 + 标签栏 46），两条分隔线错开 46px ⇒ 把品牌区加高到 102 让两线共线。
② 2026-09-19 下午：「logo 留白这么多好奇怪」→ 品牌区仍 102、logo 居中。
③ **结构重排**：面包屑行整行撤掉，顶部只剩**一行**（= 标签栏那一行）⇒
品牌区回到与它同高，两线天然共线，**前面两次的张力一次消失**（不再有"对齐 vs 留白"之争）。
⇒ 所以现在这里既没有 `calc(header + tabs)`、也没有 `padding-bottom`，
更不需要 `:has()` 判断标签栏在不在 —— 结构简化后这些补丁全都不需要了。
▸ 2026-09-20：标签栏高度收回（乐哥「最上面的标签有点大」），品牌区**跟着一起收**
—— 就是靠共用 `--tabs-bar-height` 这一个令牌自动跟上的，不改一行代码。
⚠️ 若哪天把品牌区改成写死高度，这个"自动共线"就会断，必须显式对齐。
⚠️ 若将来把面包屑行加回来：品牌区要改回 `calc(--header-height + --tabs-bar-height)`
并恢复 `:has(.page-tabs-bar:not(:empty))` 的守卫（原因见 git 历史与本文件旧注释）。 */
.brand-logo {
width: 36px;
height: 36px;
display: flex;
align-items: center;
justify-content: center;
flex-shrink: 0;
}
.brand-logo img {
/* ⚠️⚠️ `width: auto` + `height: 100%`（**不要** `width:100%; height:100%`）：
公司标识长宽比是 0.897（高>宽），容器是正方形。
写成 100%/100% 时**元素框**会变成正方形（图形虽经 object-fit 等比缩放没变形，
但 `getBoundingClientRect()` 量出来是 36×36 ⇒ 核验脚本会误报"被压扁"，
以后维护的人也会以为它变形了）。
按高定尺后元素框本身就等于图形尺寸，一眼可验、也不会被误改。
⚠️ 这里**只管尺寸**；`object-fit` / `display` / 拖拽禁用等通用行为统一放在
`.brand-mark`（见下方），两处不要重复写 —— 职责分开才好维护。 */
width: auto;
height: 100%;
}
/* ⭐ 公司标识（八芒星）的**通用行为** —— 2026-09-20 乐哥给图换的，全站统一
（实现见 js/icons.js 的 `logo()`，它给每个 img 都挂了这个 class）。
⚠️ 职责划分：**尺寸**由各容器自己定（`.brand-logo img` 用 height:100%、
门户 30px、财务 28px、登录 44px…因为各处想要的视觉大小不同）；
本 class 只管**与尺寸无关的通用行为**，避免在每个容器里重复抄一遍。
⚠️⚠️ `object-fit: contain` **不能删**：标识长宽比 **0.897**（高>宽），
而多数容器是正方形。没有 contain 时，若某处容器写的是
`width:100%;height:100%`，图片就会被**横向拉宽**（压扁变形）——
那种"看着有点怪、但说不上哪不对"的错最容易被漏掉。
⚠️ `vertical-align: middle` 治的是 inline 图片在行内基线的**下方空隙**
（图片默认按基线对齐，会给容器多出几个像素高度、把布局顶偏）。
⚠️ 禁拖拽/禁选中：标识不是内容，被拖出去或双击选中会显得像网页坏了。
⚠️⚠️ `margin: 0`（**不是 `margin: 0 auto`**）—— 2026-09-22 乐哥：
「所有页面 logo 位置，左对齐吧」。
**为什么原来居中是错的**：`.login-hero__logo` 是**普通 block**、宽度由内容撑开
（实测三个登录门面分别是 328 / 188 / 297px），`margin: 0 auto` 会把图标
居中到这块宽度里 ⇒ **三个登录页的 logo x 位置各不相同（271 / 201 / 255）**，
而标题、副标题、标签全是左对齐的 ⇒ 图标独独居中，看着就是"没对齐"。
⇒ 改成 `margin: 0` 后图标贴容器左边，与标题同一竖线。
⚠️ **不影响侧栏**（达播/财务）：`.brand-logo` 是 `flex + justify-content: center`，
auto margin 去掉后由 flex 居中接管 ⇒ 位置一模一样（实测仍在 x=18）。
⚠️ **也不影响折叠态**（`.app-shell.is-collapsed .sidebar .brand-logo { margin: 0 auto }`
—— 那是**容器自己**的 margin，与 img 无关）。
⇒ 这条修改的净效果：登录页 logo 左对齐（本次要修的），其余位置不变。 */
.brand-mark {
object-fit: contain;
display: block;
margin: 0;
vertical-align: middle;
user-select: none;
-webkit-user-drag: none;
-webkit-user-select: none;
}
.brand-name {
display: flex;
flex-direction: column;
gap: 1px;
min-width: 0;
overflow: hidden;
}
.brand-name__en {
font-size: var(--font-size-xs);
font-weight: var(--font-weight-medium);
letter-spacing: 0.03em;
color: var(--color-meta);
line-height: 1.2;
white-space: nowrap;
overflow: hidden;
text-overflow: ellipsis;
}
.brand-name__zh {
/* ⭐ 20 → 18px + 名称简化为 6 字（2026-09-21 乐哥拍板"缩小+简化"，
原话：「星盟达人管理后台 这个名字有点长，放在左上角感觉不协调，
你看是缩小文字，还是缩小文字+简化文字」）。
──────────────────────────────────────────────────────────────────────
▸ 为什么必须**两件事一起做**（"不协调"实测是三个来源叠加，不是单一问题）：
| 来源 | 改前 | 改后 | 靠什么解决 |
|---|---|---|---|
| 顶到边 | 余量 4px（仅 0.2 个字的空隙） | 余量 56px | 简化 + 缩小 |
| 盖过菜单 | 20px ÷ 菜单项 14px = 1.43 倍 | 1.29 倍 | 缩小 |
| 两行悬殊 | 中文 160 vs 英文 54（3 倍），左对齐成"倒 L" | 108 vs 54（2 倍） | 简化 |
⇒ **只缩小**（仅改字号）治不了"两行悬殊"；**只简化**（仅改名字）治不了"盖过菜单"。
两者成本一样（各改一个值），所以一起做，一次把三个来源都解掉。
▸ 实测宽度（真实 CSS 渲染，非估算）：
· 可用宽 = 240 侧栏 − 品牌区左右 padding 2×16 − logo 36 − gap 8 = **164px**
· 「星盟达人后台」6 字：16px→96 / **18px→108** / 20px→120 / 22px→132
· 规律：**CJK 每字正好 1em**（8 字 20px = 160px 实测验证过，故可直接按字数×字号算）
⇒ 18px 占 108px，余 56px —— 余量充足，换字体/加权都不会截断。
▸ 比例仍在参照物同一量级：18 / 36 = **0.50**（微信小店的「文字/图标」高度比约 0.55；
被乐哥指出"不够醒目"时是 16/36 = 0.44）。故 0.50 是"既收回体量、又不回到偏小"的位置。
⚠️⚠️ 这里**直写 18px、没有用令牌** —— 这是本项目唯一的裸字号，理由：
令牌阶梯对齐 TDesign（12/14/16/20/24/30/36…），**没有 18 这一档**
（pages.css 里也有一条既有说明："令牌表里没有 md"）。
18px 是本设计真的需要的档位，但**不为此扩阶梯**：扩一档会让全站多一个可选值，
而目前只有这一处需要它。⇒ tests/brand-home.test.js 的 A1 已相应放宽为
"允许裸的 18px，其余一律必须用令牌"，别把这条当"可以随便写裸值"的先例。
⚠️ 手机端（≤768px）行为**完全不变**：原来用 --font-size-xl，它在断点里就是 18px；
现在写死 18px ⇒ 手机端与改前逐像素相同，只有桌面端 20 → 18。
（若将来想让手机端再小一点，**必须**显式加断点，不会再自动跟随了。）
⚠️ 改本条要连带看 .sidebar__brand 的 gap —— 两者仍是"抢宽度"的成对关系
（tests/brand-home.test.js 的 A2 有算术断言：可用宽 ≥ 名字实际需要宽）。
现在余量 56px 很宽裕，但**别因此把 gap 调大**：gap 变大同时会把菜单区视觉推挤。 */
font-size: 18px;
font-weight: var(--font-weight-semibold);
letter-spacing: var(--font-letter-spacing-body);
color: var(--color-fg);
line-height: 1.3;
white-space: nowrap;
overflow: hidden;
text-overflow: ellipsis;
}
.sidebar__nav {
flex: 1;
overflow-y: auto;
/* ⭐ 2026-09-25 菜单加高到 52px 后，导航区内容（实测 922px）超过可用高度（约 695px）
⇒ 菜单**可滚动**。但原滚动条是"透明、仅 hover 显色"，用户看到菜单在"业绩管理"处
被切断会以为**菜单丢了**（乐哥报「看板页很奇怪」的一部分就是这个观感）。
⇒ 改成"常驻淡显 + hover 加深"：一眼能看出"下面还有"，也不抢视线。
⚠️ 与全站其它滚动条（body / 侧栏本身）的"hover 才显"不同 —— 那一套适合"内容明显
超出、用户预期能滚"的场景；这里是**主菜单**，可见性优先。 */
scrollbar-color: var(--color-gray-300) transparent;
/* ⚠️ 这里**故意不写** overscroll-behavior —— 由外层 .sidebar 那一条统一负责。
实测（.render-check/probe-sidebar-scroll.js）：只留 .sidebar 那条时行为断言全绿；
而只留本条、去掉 .sidebar 那条时，**搜索入口与底部「我的」区会穿透**
（它们不在本元素内，本元素的 contain 管不到）。
⇒ 一条放在最外层即可覆盖全部；放在这里反而只覆盖导航区，是**更弱**的方案。 */
/* ⭐⭐ 2026-10-06：上下 8、**左右 12**（左右从 space-2=8 提到 12）——
配合菜单项左右内边距 22 ⇒ 文字落在 12+22+16+12 = **62px**，
与品牌名、分组标题、二级子项**同一条竖线**。
算式：容器 12 + 项 22 + 图标 16 + gap 12 = 62。
⚠️ 改这一串任一个值，都要同步验"四级文字是否还对齐"（这是本项目最容易失守的隐性约束）。
⭐⭐⭐ 2026-10-08 14:5x **上内边距 43 → 0**（留白并进品牌区，见 `.sidebar__brand`）
· 起因（乐哥原话）：「如果菜单栏展开了很多，滑动的时候，**也不要突破这个界限**，
如果突破的隐藏了」——他画的那条红线在 y=92（= 页头卡顶边）。
· ⛔ 病根：`padding-top` 长在**滚动容器内部** ⇒ 滚动内容可以进入这段留白，
菜单项上滑时会出现在「logo 下方那段空档」里，只在**容器外缘**(y=60)被裁住
⇒ 视觉上越过了他画的那条线。**这不是调参能解决的，是留白的归属问题。**
· ✅ 修法：留白挪进 `.sidebar__brand`（品牌区 60 → 92，走 `--sidebar-brand-h`），
本元素上内边距归零 ⇒ 滚动容器上缘 = 92 = 裁切边 ⇒ 物理上滑不出去，
不需要遮罩、不需要 JS。
· ⚠️ 旧令牌 `--sidebar-nav-pad-top` 已删除；`margin-top` 也不要加（等价于把
留白又放回容器外，但会让"菜单起始线"与"品牌区下沿"变成两个可漂移的数）。
· ⛔ **左右 12px 一个字没动**：它撑着「竖向基线 62」，动了四级文字会错位。 */
padding: 0 12px var(--space-2);
scrollbar-width: thin; /* Firefox */
scrollbar-color: transparent transparent;
}
.sidebar__nav:hover {
scrollbar-color: var(--color-gray-300) transparent;
}
.sidebar__nav::-webkit-scrollbar { width: 6px; }
.sidebar__nav::-webkit-scrollbar-thumb { background: var(--color-gray-300); border-radius: 3px; }
.sidebar__nav:hover::-webkit-scrollbar-thumb { background: var(--color-gray-400); }
.sidebar__nav::-webkit-scrollbar-track { background: transparent; }
.nav-item {
display: flex;
align-items: center;
gap: var(--space-3);
/* ⭐⭐ 2026-10-06 紧凑档（乐哥：「每个菜单选项都有点太高了，但是做太矮的话和呼吸感又冲突」）：
▸ 高度 52 → **44**（行高降下来，一屏能放更多项）；
▸ 左右内边距 12 → **22**（**呼吸感由横向留白承担**，不是行高）。
⭐ 算式：侧栏容器 padding-left 12 + 本项 22 + 图标 18 + gap 12 = **62**
= 品牌名/分组标题/二级子项文字的同一竖线（改任一项都要重算这一串）。
⚠️ 52 是 09-25 按"参考图更舒展"定的；本次参考图的菜单更密（36~42），
且我们侧栏有 9 组 29 项 —— 52px 会让"展开一组就滚动"。 */
/* ⭐⭐⭐ 2026-10-07 22:55 **44px → 42px**（乐哥：「菜单栏的文字，就是首页那个，
按照右边悬浮 tab 栏的高度来吧，我红线有标」）
────────────────────────────────────────────────────────────────────────────────
▸ 实测参照物（真机，不是印象）：
右侧 `.table-tabs--in-header` = **42px**（19:45 那批刚统一的档）
页头 `.page-actions .btn` = **42px**（同一批）
侧栏一级项原来 = **44px** ⇒ 差 **2px**
⇒ 改 42 ⇒ 一级项与 tab 栏、主按钮**三者完全一致**。
⚠️ 为什么不是反向把 tab 栏改成 44：那个高度 19:45 刚统一过
（搜索框 / 月份框 / 按钮四个控件全按 42 做的），改它要连带三个控件一起动。
⚠️ 走**新令牌** `--nav-item-h` 而非复用 `--control-height-row`：
后者语义是「页头筛选行控件」，混用会让侧栏项高被页头控件的调整带走。
⚠️ 竖向基线 62（容器12 + 项22 + 图标16 + gap12）是**横向**的，不受本条影响。 */
height: var(--nav-item-h);
padding: 0 22px;
margin-bottom: 0;
border-radius: var(--radius-md);
color: var(--color-fg-2);
/* ⭐⭐⭐ 同批 22:55 字号 14 → **15px**（乐哥：「依次菜单文字字号大一点，现在太小了」
22:55 拍板走「**整体变大**」：分组 13→14、一级 14→**15**、二级 13→14）
⚠️ 为什么一级从 `var(--font-size-base)` 改成字面量 15：
令牌阶梯 12/14/16 里**没有 15**，而 `--font-size-lg` 是 16（用于卡片标题，
侧栏菜单用 16 会太重、且它还被 `.brand-name__zh` 等占用）。
⛔ 禁止为此新造 `--font-size-15`：design-tokens 注释明写
「字号阶梯对齐 TDesign，禁止再降到 13px」—— 那是**正文**下限，
但新造一档会让 15px 在两个含义间漂移（同 13px 那次一样的坑）。
⇒ 行内字面量 + 本注释说明，判据按**值**锁。 */
font-size: 15px;
font-weight: var(--font-weight-medium);
cursor: pointer;
white-space: nowrap;
transition: background-color var(--motion-fast) var(--motion-ease-standard),
color var(--motion-fast) var(--motion-ease-standard);
}
.nav-item:hover {
background: var(--color-surface-2);
color: var(--color-fg);
}
/* 激活态：浅主色底 + 主色文字（克制，不抢焦点）
⭐ 2026-09-25 Gashora 像素级试妆：参考图的当前项是「浅灰圆角背景 + 黑字 + 右侧紫色竖条」。
侧栏是白底，故当前项用**界面底色**（#F8F8F8，比白稍灰）才能显出；近黑字 + 右侧品牌色竖条。 */
/* ⭐⭐ 2026-10-06 选中态（首页 / 我的提成这类"一级平铺项"）：整行浅蓝胶囊 + 主色文字。
同 `.nav-item--sub.is-active` 的理由（侧栏无底后必须换色，否则看不见）。 */
/* ⭐⭐⭐ 2026-10-07 15:20 选中态：**白卡浮起**（乐哥选「白卡浮起（同飞书，推荐）」）
────────────────────────────────────────────────────────────────────────────────
▸ 改前 = `--color-accent-bg`（淡蓝底）+ 主色文字（10-06 那版）。
▸ 改后 = **白底 + 轻阴影 + 近黑字**，与飞书一致。
为什么现在才换：底色从中性灰改成**清新蓝**（#E3EEFB）之后，
淡蓝选中底与蓝底色**同色系、贴在一起** ⇒ 选中项的"胶囊"读不出来
（实测：那会儿选中块几乎融进侧栏）。白卡是唯一能与蓝底拉开层次的选择。
⚠️ 三处必须一起改（否则"选中"在三个位置表现不一致）：
① 本条（一级平铺项，如"首页"）
② `.nav-item--sub.is-active`（二级项，在下面）
③ 分组标题 `is-active` 那态（`.nav-group.is-active .nav-group-label`）
⚠️ 阴影刻意很淡（.09）：侧栏底色本身已是浅色，白卡再重影会显脏。
⚠️ `::after` 那条右侧竖条继续保持 `display:none`（10-06 已删，见下）。 */
.nav-item.is-active {
background: var(--color-surface);
color: var(--color-fg);
/* ⭐⭐⭐ 同上（2026-10-08 15:1x）：选中态由"浮起"改**平卡** + 字重 600 → 500。
依据：真机量飞书选中项**没有投影**，且**不加粗** ——
墨密度实测：选中「消息」0.359，未选中「云文档/日历/任务/邮箱」0.273/0.305/0.301/0.406
⇒ 选中那个**落在未选中区间之内**，说明飞书不靠加粗表达选中（靠"深色字 + 近白平卡"）。
⚠️ 一级（15/500）与二级（14/400）的**层级仍靠字号+基准字重表达**，不受本条影响。 */
font-weight: var(--font-weight-medium);
box-shadow: none;
position: relative;
}
/* ⚠️ 2026-10-06：**右侧蓝色竖条已删** —— 参考图的选中项是"整行胶囊"，没有右侧竖条；
有胶囊之后再挂竖条会变成两个选中信号（本项目纪律：同类状态只用一种表达）。 */
.nav-item.is-active::after {
display: none;
}
.nav-item .nav-icon {
flex-shrink: 0;
display: inline-flex;
}
.nav-item .nav-text {
flex: 1;
overflow: hidden;
text-overflow: ellipsis;
}
/* ⭐ 「返回门户网站」入口（2026-09-21 新增）—— 侧栏底部，达播与财务都有。
⚠️ 为什么单独一个类、不复用 `.nav-item`：
它**不是本应用的页面**，而是"离开本应用"（门户是真实路径 ⇒ 整页跳转）。
混进 `.nav-item` 会被侧栏那套 `[data-nav]` 绑定挂上 `navigate()` ——
而 navigate 只改 hash ⇒ 变成 `#/hub`，**点了没反应**（本项目已明确否掉那个形态）。
⚠️ 盒子模型与 `.nav-item` **逐项一致**（gap 12 / 高 40 / 左右内边距 12 / 圆角 8），
只有**颜色更轻**：它是次要操作，不该抢菜单的注意力。
⚠️⚠️ 颜色两次调整的账（2026-09-21 乐哥：「当前文字颜色好暗」）：
原用 `--color-meta`(#8595A4) —— 在白底上对比度只有 **3.07:1**，
**低于 WCAG AA 正文要求的 4.5:1** ⇒ 发灰、"糊"。
现用 `--color-muted`(#5D6C7B) = **5.32:1**，达标。
⇒ 判"文字是不是太暗/太灰"要**算对比度**，不要凭观感 ——
3.07 与 5.32 在截图上看差别不大，但一个是"没达标"、一个是"达标"。
⚠️ `text-decoration: none` 不能删：它是 ``，默认带下划线。 */
.sidebar-portal {
display: flex;
align-items: center;
gap: var(--space-3); /* = .nav-item 同款，供左侧图标与文字之间用 */
height: 40px;
padding: 0 var(--space-3);
margin-bottom: 2px;
border-radius: var(--radius-md);
color: var(--color-muted);
font-size: var(--font-size-sm);
text-decoration: none;
white-space: nowrap;
transition: background-color var(--motion-fast) var(--motion-ease-standard),
color var(--motion-fast) var(--motion-ease-standard);
}
/* 左侧图标（2026-09-21 第三次改加回）——
⚠️ 尺寸必须是 **16px**：18px（= 侧栏一级菜单）在本行会**与下方「我的」的 32px 头像
在体量上打架**（这是上一次被否的真正原因）。16px 的中心正好与头像中心同轴（都在 x=28），
既对齐又不抢戏。
⚠️ 颜色跟随文字（`currentColor`），hover 时随整行一起变深 —— 不要单独给图标写颜色。 */
.sidebar-portal__icon {
flex-shrink: 0;
display: inline-flex;
align-items: center;
color: var(--color-meta); /* 比文字再轻一档：图标是辅助，文字才是要读的 */
}
.sidebar-portal:hover {
background: var(--color-surface-2); /* = .nav-item:hover 同款令牌，不新造颜色 */
color: var(--color-fg);
}
.sidebar-portal:hover .sidebar-portal__icon { color: var(--color-muted); }
/* ⚠️ 焦点环：显式写一条，**不依赖**全局那条
`:where(button,[role=button],[tabindex]):focus-visible` ——
它是 ``（天然可聚焦），不在那条选择器的覆盖范围里。
用了全站同一套颜色与粗细，只是偏移向内收（与侧栏其他通栏元素一致）。 */
.sidebar-portal:focus-visible {
outline: 2px solid var(--color-accent);
outline-offset: -2px;
}
/* ⚠️⚠️ 文字**不参与收缩、也不裁剪** —— 这条是本轮 UI 问题的根治点，别改回去。
──────────────────────────────────────────────────────────────────────────
症状（乐哥截图）：文字显示成「返…」（4~6 个字被截掉），且线上图标与文字紧贴。
实测根因（脚本量出来的数据）：
· 文字「返回门户网站」的**自然宽 = 84px**（6 个全角字 × 14px）
· 但它的盒子在某些渲染时机只被给到 **~77px** ⇒ `scrollWidth(84) > clientWidth(77)`
⇒ `text-overflow: ellipsis` 生效 ⇒ 截成「返…」。
原因就是这里原来写的 `flex: 1 1 0%` **让文字跟着 flex 收缩**：
本行总宽 223 − 左右 padding 24 − 尾部箭头 16 − ……，留给文字的余量会被挤。
⇒ 改成 `flex: 0 0 auto`：文字按自己的自然宽（84px）占位，**永远放得下** ——
本行可用宽约 199px，装 84px 文字 + 16px 箭头绰绰有余。
同时 `overflow: visible` 兜底：万一将来标签改长，宁可让它溢出（容易发现），
也不要静默变成「…」（本轮就是"静默截断"骗过了所有只看 DOM 数值的检查）。
⚠️ 这也解释了为什么"只比 md5 / 只 grep 文件内容"发现不了问题：
样式文件是对的、DOM 也是对的，只是**渲染被裁了**。
接口分界线：这类问题必须**看渲染结果**（截图取样）才发现。 */
.sidebar-portal .nav-text {
flex: 0 0 auto;
overflow: visible;
text-overflow: clip;
white-space: nowrap;
}
/* 尾部箭头（`›`）推到最右 —— 与正下方「我的」那行的尾部箭头同构，
表达"去往下一层 / 离开这里"，正是乐哥提的形态（「放个 > 之类」）。 */
.sidebar-portal__arrow {
margin-left: auto;
display: inline-flex;
color: var(--color-muted);
}
/* ⭐⭐ 「切换系统」下拉（2026-09-30）—— 乐哥：「点左下角，能快速切换其他网站吗」
──────────────────────────────────────────────────────────────────────────
与正下方「我的」**同构**：都是"侧栏底部、点开**向上弹**"的小面板
（底部区域没有向下弹的空间，向下弹会出屏幕）。
⚠️ 触发器由 `` 改成了 `