|
|
@@ -2399,3 +2399,33 @@
|
|
|
这类"同值覆盖"在改基础值后会变成有效覆盖(本轮 Session 058 已经踩过一处 28px 的)
|
|
|
- **下一步最佳动作**:真机看一眼移动端标题;确认窄屏那条覆盖是否要恢复
|
|
|
|
|
|
+## Session 060
|
|
|
+
|
|
|
+- **日期**:2026-09-18
|
|
|
+- **本轮目标**:用户指示「移动端调整到 22px」(PC 不动)
|
|
|
+- **已完成**:
|
|
|
+ - 移动端 `.heading`:`clamp(17px, 5.2vw, 20px)` → **`clamp(17px, 5.7vw, 22px)`**
|
|
|
+ (基础值同步改 22px;**两行一起改**,见 Session 059 的坑)
|
|
|
+ - `5.7vw` 这个系数是**按上限等比推的**(原 5.2vw 对应上限 20px):
|
|
|
+ ≥386px 的屏恒为 22px,更窄的屏按比例收缩
|
|
|
+ - PC **未动**(保持 32px)
|
|
|
+ - 注释里写清了这一串演进(20 → 16 → 20 → 22),免得下个会话看到 clamp 系数变化不明所以
|
|
|
+- **运行过的验证**:
|
|
|
+ - `npm run build` 通过
|
|
|
+ - **排版实算(脚本,9 种屏宽)**:全部单行放得下 ——
|
|
|
+ 386px 及以上生效 22px(富余 ≥36px);375px 生效 21.4px;360px 生效 20.5px;
|
|
|
+ 320px 生效 18.2px(**富余仅 3px,是最紧的一档**)
|
|
|
+ - 同时算出各屏上限:320px 屏最多 18.5px、360px 最多 21.6px、375px 最多 23.9px
|
|
|
+ → **22px 在 375px 及以上才完整生效**,360px 上会收到 20.5px(**不是 bug,是防溢出**)
|
|
|
+- **已记录证据**:本文件 Session 060;上面的排版实算输出;README 20260918 节
|
|
|
+ (该条已改写为「当前值:PC 32px / 移动端 22px」,并列出反复过程)
|
|
|
+- **提交记录**:见下条提交(已按约定提交推送)
|
|
|
+- **更新过的文件或工件**:`src/components/BusinessAssistantMobile.vue`、`README.md`、本文件
|
|
|
+- **已知风险或未解决问题**:
|
|
|
+ - ⚠️ **未在真机看过**:需确认 22px 的观感
|
|
|
+ - ⚠️ **若用户手机上看着"没到 22px"**:多半是屏宽 360px 档(生效 20.5px)。
|
|
|
+ 要么接受,要么把 clamp 系数加大(但 360px 屏容不下 22px,会溢出)
|
|
|
+ - ⚠️ 320px 档富余只剩 3px,字体渲染有细微差异时可能贴边——真机若见贴边,
|
|
|
+ 把下限或系数再收一点
|
|
|
+- **下一步最佳动作**:真机确认观感;若还要更大,需要先解决"窄屏放不下"这个硬约束
|
|
|
+
|