一、为什么要重新设计天气组件#

这次改动之前，项目中的天气组件和独立预览稿并不是同一个设计。两边虽然展示了相近的数据，但 DOM 结构、间距、图标比例和信息排列方式都不同。预览稿看起来像一个完整的天气场景，项目组件却更接近传统的数据卡片。

随着气压、AQI、云量、紫外线、降水、日出日落以及 PM2.5、PM10、O₃、NO₂、SO₂、CO 等数据加入，问题变得更加明显：

• 所有信息平铺在同一层，用户很难判断什么最重要。
• 桌面端高度偏高，横向空间没有被充分利用。
• 移动端如果直接缩小桌面布局，底部数据容易被挤压或看不完整。
• 预览稿和实际组件分别维护，视觉调整很容易产生偏差。

所以这次重构首先解决的不是某一个 CSS 属性，而是确定一个唯一的视觉基准。

二、先确定统一的视觉基准#

最终采用预览稿中的 Responsive weather scene 作为项目组件的唯一设计参考。这个名字代表的不是一张固定的卡片，而是一套根据屏幕形态改变构图的规则：

• PC 端使用横向场景，让左右空间承担不同职责。
• 移动端使用竖向场景，让核心天气信息优先进入首屏。
• 两端使用相同的数据来源和语义，只改变排列方式。
• 预览稿中的视觉类名和组件中的结构保持对应，避免“预览是一套、项目又是另一套”。

统一基准之后，后续的高度、间距、图标大小和动画节奏就不再是零散调整，而是围绕同一个场景进行取舍。

三、PC 端：把信息展开成横向场景#

桌面端的重点是利用横向空间，而不是继续向下堆叠内容。

左侧负责建立天气认知：地点、当前温度、天气状态和今日最高/最低温度放在一起，用户进入页面后可以快速知道“这里的天气怎么样”。右侧负责承载图标和环境指标，天气图标成为视觉锚点，其余指标按照统一的标签和值进行排列。

这种布局把信息分成了两个区域：左侧是结论，右侧是依据。用户先看到 17°C · 晴 这样的核心状态，再决定是否继续读取风力、湿度、能见度、体感温度和环境数据。

污染物浓度单独放在右侧区域的底部，并固定为一排：

六项数据保持同一行有两个好处：一是用户可以快速横向比较，二是避免污染物列表继续拉高容器。为了保证它在不同宽度下仍然稳定，卡片内部使用六列等宽布局，文字过长时也不会破坏整体结构。

在高度控制上，重点压缩的是无意义的留白，而不是压缩文字本身。标题、温度和指标之间保留清晰的呼吸空间，同时减少重复的上下间距，让横向布局真正承担“降低高度”的作用。

四、移动端：先保留核心，再展开完整数据#

手机端的空间更紧张，所有数据同时出现会让用户第一眼看到一块很高的面板。因此移动端采用“核心信息默认可见，完整数据按需展开”的策略。

默认状态只保留天气图标、地点、温度、天气状态和高低温范围。这些信息足以完成一次快速查看，也能让组件在手机首页保持轻量。

气压、AQI、云量、紫外线、降水量、降水概率、日出、日落，以及六项污染物数据被放入下方的数据区域。底部增加一个带箭头的“打开完整数据”按钮，点击后再展示剩余内容；再次点击可以收起。

这里的折叠不是为了隐藏数据，而是把数据的阅读时机交给用户。天气组件作为首页的一部分，默认应该安静地占据有限空间；当用户确实需要更详细的环境信息时，再通过一次明确的操作获取完整内容。

五、背景图如何成为氛围层#

背景图不再只是铺在卡片后面的装饰，而是天气场景的一部分。PC 端使用 https://t.alcy.cc/pc，移动端使用 https://t.alcy.cc/mp，让不同屏幕比例下的构图更自然。

但背景图本身不能直接承担文字对比度。因此组件在图片上增加了深色渐变遮罩，并叠加轻微的颗粒纹理：

• 渐变遮罩负责压住过亮区域，让白色文字保持可读。
• 颗粒纹理减少纯色渐变的单调感，让背景更接近一张有质感的场景图。
• 圆角和裁切保证图片不会脱离卡片边界。
• 背景接口失败或没有返回内容时，使用默认天气主题渐变，不影响数据卡片继续显示。

这里的原则是：背景负责营造情绪，前景负责传递信息。任何氛围效果都不能以牺牲阅读为代价。

六、信息展示的优先级#

天气接口返回的数据很多，但不代表所有字段都应该拥有相同的视觉权重。重排之后，信息大致分为四层：

1. 核心天气：地点、当前温度、天气状态、最高温和最低温。
2. 即时体感：风力、湿度、能见度、体感温度。
3. 环境数据：气压、AQI、云量、紫外线、降水量、降水概率、日出和日落。
4. 污染物浓度：PM2.5、PM10、O₃、NO₂、SO₂、CO。

第一层决定用户是否需要进一步阅读，第二层帮助用户理解体感，第三层和第四层则服务于更细的环境判断。这个层级同时应用在桌面端和移动端，只是移动端通过折叠把后两层延后展示。

这也解决了一个常见问题：当某个接口字段没有返回时，组件不应该因为缺少一个数据就改变布局。各个指标保留稳定的位置，并使用 — 作为占位，整体结构不会跳动。

七、让动画服务于阅读#

PC 端天气卡片采用从右侧横向进入的方式，让它像一个场景面板一样进入页面，而不是突然出现在视野中。最初的动画速度过快，视觉上更像切换状态，无法体现背景和内容逐渐展开的感觉。

因此入场动画调整为 1.25 秒，并使用更平滑的缓动曲线。这个速度不会拖慢页面使用，却能让用户感知到组件的进入过程。天气图标保留自身的轻微动态，数据内容则避免叠加过多动画，以免信息阅读受到干扰。

同时，组件尊重 prefers-reduced-motion 设置。当用户系统偏好减少动态效果时，入场和装饰性动画会被关闭，内容本身仍然正常显示。

八、这次重构留下的设计经验#

这次天气组件改动最重要的结果，不是增加了多少数据，而是建立了数据、布局和氛围之间的关系。

第一，预览稿不能只作为展示截图，真正可复用的是它背后的结构和视觉语义。只有让预览和项目组件使用同一套布局概念，后续修改才不会再次产生偏差。

第二，响应式设计不是把桌面端压缩到手机屏幕上。桌面端和移动端面对的是不同的阅读场景，前者适合同时比较多个指标，后者更适合先快速确认状态，再主动展开细节。

第三，数据越多，越需要明确优先级。天气组件并不需要把所有字段都放在第一眼可见的位置，而是要让每一层信息都有合适的出现时机。

最后，背景、图标和动画都应该服务于内容。它们可以让组件更有氛围，但不能抢走温度、天气状态和关键指标的注意力。一个好的天气组件，最终应该让用户先感受到天气，再意识到它背后有一套完整的数据组织。