better-layout

用布局传递清晰结构

用户还没读到一个字，布局就已经在传递信息了：位置、间距与对齐本身就代表着层级秩序，充足留白远胜繁复装饰。优秀的布局还要经得住“极限测试”：无论缩放窗口、多语言翻译，还是镜像切换为 RTL（从右到左），整体结构都不应崩塌。请在编写或审查 UI 代码时运用这些原则，并始终使用项目原有的样式系统（如 Tailwind、原生 CSS、CSS-in-JS）来实现改动；切勿引入第二套样式方案。

点击区域（热区）大小与焦点行为由 better-accessibility Skill 负责；视觉精致度（圆角、阴影、动画）由 better-ui Skill 负责；文本行长与字间距由 better-typography Skill 负责。

对于尚未建立明确密度或间距规范的界面，请将下文给出的数值作为起点。如果既有的平台 Chrome 框架、紧凑型专业工具界面或项目样式 Token 在热区大小、缩放、本地化及视口压力测试下表现依然良好，应予以保留。

快速参考

分类	适用场景
Grouping & Alignment	留白 vs 分隔线、对齐边缘、逻辑属性、按重要性排序
Spacing & Adaptivity	交互目标间距、布局边距、渐进式呈现、全屏无边框（full-bleed）内容、响应式断点、国际化文本膨胀

核心原则

1. 用留白分组，而不是线段

留白（负空间）是首选的分组工具；背景形状次之；分隔线仅在单纯靠留白无法维持结构时作为兜底手段。组间间距（inter-group gap）必须至少是组内间距（intra-group gap）的 2 倍（例如组内 8px → 组间 16px 及以上），否则视觉分组就会沦为毫无意义的噪点。

2. 区分交互控件与静态内容

交互元素必须具备明确的可交互外观：比如有背景块、边框，或位于固定的操作区域内。切勿将控件样式设计得与相邻的静态文本一模一样。

3. 对齐公共边缘

选定几条基准对齐线并坚持使用；任何游离在外的边缘都会带来视觉混乱。每增加一层层级递进，统一递增一个项目标准的间距步长（推荐以 16px 作为起点）。涉及方向相关的布局时，优先使用逻辑属性（如 padding-inline-start、margin-inline-end）；仅在处理真正物理意义上的几何布局时才使用左右物理属性（left/right）。

4. 按重要性确定阅读顺序

最重要的内容应靠近顶部和起始边缘（Leading edge）；视线流向由上至下、由起始端到末端（Trailing edge）。养成用“起始端/末端”替代“左/右”的思考习惯。

5. 对隐藏内容提供视觉暗示

渐进式呈现（Progressive disclosure）必须提供显眼的视觉引导。优先使用项目中已确立的提示样式；若无规范，可让下一个元素在滚动边缘露头 16–32px，或提供显式的展开/折叠控件。没有任何视觉暗示的隐藏内容，等同于不存在。

6. 交互目标之间保持呼吸感

在缺乏既定密度系统的情况下，相邻的有边框/有填充控件之间建议保持至少 12px 间距，无边框的纯文本/图标控件周围建议留出 24px 的安全边距。在紧凑布局中，只要满足 better-accessibility Skill 规定的热区不重叠且控件依然清晰可辨，可适当缩减间距。

7. 按钮与屏幕边缘保持内收

在常规内容布局中，通栏按钮也应内嵌于布局边距之内（移动端左右内收通常建议以 16px 起步），并保持明显的圆角。只有在明确遵循成熟的平台/应用框架规范、处理好了安全区域（safe area）、且能与系统原生 UI 做出清晰区分时，才允许使用贴边无缝（edge-to-edge）的操作按钮。

8. 内容铺满出血，控件悬浮固定

背景与媒体元素可以延伸至视口边缘（Bleed）；但控件和文本必须严格保留在布局边距与安全区域（env(safe-area-inset-*)）之内。吸顶/吸底的框架组件（Sticky chrome）应当悬浮在内容层之上，而不是截断内容流动。

9. 布局能撑多久撑多久，临界时再断点折叠

响应式断点应基于内容本身决定，而非死板套用设备预设尺寸。只要界面空间确实充裕，就尽可能维持展开状态，尽量推迟折叠时机；对于组件层级的自适应，优先推荐使用容器查询（container queries）。测试时应优先验证极小视口与极大视口。

10. 预留文本膨胀空间，防止裁切溢出

不同语言翻译后文本长度可能会大幅膨胀，不能死板假设固定的增长比例：切勿在文本容器上写死固定宽高，应允许文本自然换行。绝对不要把关键操作摆放在会被窗口缩放或滚动条裁切的死角；确保它们在正常文档流中随时可见，或者固定在符合产品规范的常驻框架区中。

常见错误

常见错误	修复方案
能够靠留白解决的地方误用了分隔线	移除分隔线，将组间间距翻倍
在需要支持国际化的布局中使用了 margin-left / padding-right	改用逻辑属性 margin-inline-start / padding-inline-end
内容布局中的按钮意外贴满屏幕边缘	内嵌到项目规定的边距以内；仅在有意遵循平台 Chrome 规范时才保留贴边
走马灯/横向滚动区看起来像是已经到了尽头	让下一个卡片/元素在边缘露头 16–32px
相邻控件粘连或扩展后的点击热区重叠	按项目间距规范加大间距；可将 12px / 24px 作为起始参考值
仅仅因为是默认值就在 768px / 1024px 设置断点	只有当内容在当前宽度下确实装不下时再打断点
文本容器按单一语言硬编码固定宽度	使用 max-width 并允许自动换行；使用伪本地化（pseudo-localization）与代表性语言进行测试
主操作按钮放置在面板底部容易被裁剪的位置	使用 Sticky 吸底定位，或带有 safe-area padding 的常驻框架区

审查输出格式

仅当用户要求进行独立的布局审查时使用此格式。如果审查是由 better-interface Skill 统一协调的，请将布局领域的证据和发现提供给该 Skill，并以其输出格式、严重性标准、合并规则、数量上限和最终结论为准。

独立审查报告分为两个部分呈现。

审查发现

将所有已确认的问题按原则进行分组。使用包含 Severity（严重程度）、Location（位置）、Before（修改前）、After（修改后） 和 Why（原因） 列的 Markdown 表格呈现。切勿使用单独的 "Before:" / "After:" 行。

• Severity：HIGH 会导致在支持的视口下内容或操作被阻塞；MEDIUM 会破坏视觉层级、阅读顺序或自适应能力；LOW 属于局部的对齐或间距修饰优化。
• Location：引用 path/to/file:line。如果产物没有源文件，则标注具体的界面与组件名称。
• Before / After：展示当前布局代码以及可直接执行的替换方案。
• Why：指出所违反的原则及其对可读性或自适应能力造成的负面影响。

如果某个系统性问题重复出现，请将其合并为一行，并列出所有受影响的位置。无问题的原则直接省略。

示例

用留白分组，而不是线段

Severity	Location	Before	After	Why
LOW	src/Settings.tsx:41	每个设置行都有 border-b	移除边框；组内使用 space-y-2，组间使用 space-y-8	用留白表达分组能显著减少视觉噪点
LOW	src/ProfileForm.tsx:58	表单区块之间使用 <hr>	替换为在每个区块标题上使用 mt-10	章节层级不应依赖重复出现的分割线

对齐公共边缘

Severity	Location	Before	After	Why
LOW	src/Card.tsx:24	卡片文本设为 pl-4，卡片图标设为 pl-3	将两者统一对齐到 pl-4 边缘	公共对齐边能构建出清晰易读的视觉结构
MEDIUM	src/Nav.css:19	margin-left: 16px	margin-inline-start: 16px	使用物理属性会导致自适应方向布局失效

验证与结论

审查发现之后：

1. Verification（验证）：列出已执行的具体检查项，以及在不同视口宽度、阅读顺序、缩放倍率和 RTL 状态下的观察结果。若某项检查未执行，请明确说明仍需验证的内容。
2. Verdict（结论）：若存在任何 HIGH 级别的发现，判定为 Block；若仅存在 MEDIUM 或 LOW 级别的发现，判定为 Needs changes；仅当没有任何需要修复的发现时，才判定为 Approve。

若未发现任何问题，请省略表格，直接注明 "No actionable layout findings"（未发现需处理的布局问题），附上验证报告，并以 Approve 结尾。