告别臃肿的动画和滚动条，用纯文本天气预报找回信息获取的效率

现在的大多数天气预报网站，为了追求所谓的“视觉体验”，塞进了大量的动态背景、渐变动画和巨大的空白区域。想看一眼明天的具体气温，往往需要滚动好几屏页面，在各种广告和推荐资讯中寻找目标。这种过度设计的趋势让简单的信息查询变得低效。最近我发现了一个叫 Brolly 的天气预报站，它走了一条极端的反向路线：全站纯文本，没有任何冗余装饰，真正实现了“一眼看穿未来 7 天天气”。

Brolly 最让我惊喜的不是它的极简，而是在极简之下的“硬核”实现。很多开发者在做可视化时习惯于依赖 Chart.js 或 ECharts 等重型库，但 Brolly 竟然用纯字符实现了可视化效果。最典型的例子就是它对花粉浓度的每小时热力图处理，完全不需要图片加载，也不需要 JS 渲染复杂的图表，直接通过字符的排列和颜色深浅来传达信息。这种做法不仅让页面加载速度快到不可思议，而且在任何低端设备或弱网环境下都能稳定显示。

在交互逻辑上，Brolly 采用了非常纯粹的状态管理方式。它将所有的状态——包括查询的地理位置、具体日期以及页面的展开项——全部编码进了 URL 中。这意味着它没有依赖复杂的 Session 或 Cookie 来记录用户状态。如果你想把某个地点的天气预报分享给朋友，直接发送当前链接即可，对方打开后看到的页面内容、展开状态与你完全一致，无需再次搜索地点。这种对 URL 状态的极致利用，让它在作为工具使用时具备极高的便捷性。

从技术栈来看，Brolly 是一次典型的“不堆砌框架”的实践。后端采用了 Go 语言配合 PocketBase（基于 SQLite），前端则是最基础的 HTML/JS/CSS，且全部由后端渲染。在数据源方面，它接入了 open-meteo.com 的开放接口。

值得深挖的是它对 API 压力的处理细节。为了避免频繁请求 open-meteo.com 导致响应延迟或触发限制，作者在 PocketBase 的 SQLite 层之上实现了一个自定义的 LRU（Least Recently Used）缓存机制。这个缓存的有效期被严格设定为 5 分钟。这意味着当大量用户查询同一个城市的温度时，系统会直接从本地 SQLite 缓存中读取数据，只有在缓存失效后才会发起一次新的 API 请求。这种在轻量级数据库上构建缓存层的思路，比直接部署一个 Redis 集群要精简得多，且完全能满足一个小而美的工具站需求。

在实际使用过程中，访问 https://brolly.sh 就能感受到那种久违的“工具感”。它没有试图通过视觉冲击来留住用户，而是通过极高的数据密度和零延迟的响应速度来提升效率。这种专注解决“快速获取信息”的开发逻辑，其实给很多现代 Web 应用带来了启发：有时候，删掉 90% 的视觉装饰，反而能提升 100% 的用户体验。