前端细节打磨不要过度设计

打磨不是重建，先把用户指出的那颗钉子敲准。

前端打磨不是给项目贴金箔。真正有价值的细节通常很小：一个 hover 下划线不要超过文字，一组导航间距更紧凑，一段正文的行高终于不再像默认样式。

我现在处理这类问题的原则是：先确认现象，再缩小范围，最后只改能解释问题的那一层。

从具体问题开始

如果用户指出“这条黄线太长”，那问题可能只是 display 或伪元素宽度，不应该马上抽一个新的 Link 组件。

常见判断顺序是：

1. 先看 DOM 结构有没有现成的包裹元素。
2. 再看当前 CSS 有没有共享类可以复用。
3. 最后才考虑新增组件或变量。

下面这种写法就比到处写固定宽度干净：

.text-link {
  display: inline-flex;
  width: fit-content;
}

不要把局部问题全局化

fit-content 能解决链接下划线跟随文字的问题，但不代表所有块级标题都要改成这样。每个选择器都应该有清楚的边界。

响应式也要收敛

视口单位很好用，但直接把所有尺寸换成 vw 或 vh 很容易把页面拉坏。更稳的是用 clamp() 给它一个上下限，让尺寸随视口变化，但别失控。

• 大布局可以用视口单位。
• 细线、边框、图标尺寸继续保持固定。
• 正文阅读宽度要保留上限。
• 断点继续用明确的 px。

验收要回到页面

改完以后别只盯着 CSS diff，打开页面看一遍才算数。比如可以从 MDN 的 CSS 文档 查属性语义，但最终还是要回到本项目的视觉。

我通常会检查这些点：

• 桌面端主内容和侧栏有没有抢空间。
• 移动端有没有横向滚动。
• hover 和 focus 是否都能看见。
• 代码是否只影响本轮目标页面。

简单不是偷懒

简单的实现需要更清楚的判断。能用现有 CSS 修掉的问题，就别急着造组件；能在页面级解决的间距，就别升成全局规则。否则项目很快就会长出一堆“看起来专业、实际上没人敢改”的东西。

打磨边界表

• 用 Esc 关闭临时浮层后复查页面。
• 保持 一处问题一处修。
• 改完后检查是否影响相邻页面。