ws4kp：用 NOAA 数据复刻 90 年代天气频道的观感
基于 Web 的 WeatherStar 4000。相反，该项目旨在创建一个简单易用的界面，并最大限度地减少配置麻烦。
秒懂
- 它是什么？
- ws4kp 是一个基于浏览器的 WeatherStar 4000 模拟器，用 NOAA 的 API 提供美国本土天气数据，目标是低配置门槛的复古界面。它提供服务器与静态两种部署模式，但国际用户需要另找分支。
- 适合谁用？
- ws4kp 适合两类人：怀念 90 年代天气频道画面的美国用户，以及想学习现代 JavaScript 前端与 API 集成的新手程序员。不适合需要精确模拟 WeatherStar 4000 硬件行为的人，也不适合美国以外的用户，因为项目硬编码依赖 NOAA 的 API，境外无法获取数据。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 JavaScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题
ws4kp 解决的是怀旧需求，但方式很具体。它重现 90 年代 The Weather Channel 本地天气预报的蓝橙配色和排版风格，让老观众能在现代浏览器里看到类似当年的画面。项目作者在 README 里直接说明，这不是对 WeatherStar 4000 硬件的精确模拟，而是追求简单易用、配置最少。目标用户是两类：怀念那个年代天气节目的普通人，以及想通过实际代码学习 JavaScript 和 API 调用的开发者。它把 NOAA 的天气数据转换成复古风格的界面，省去用户自己抓取和格式化数据的麻烦。
数据流与架构：NOAA API 是唯一来源
整个项目的数据流很直接。浏览器或服务器向 api.weather.gov 发送请求，获取美国本土的预报、雷达和警报信息，然后渲染成 WeatherStar 风格的屏幕。代码明确区分了 API 层和 UI 层，API 层负责请求和解析，UI 层只管显示。项目使用了 ES6 的 async/await 和 Promise 来并行加载所有预报资源，减少等待时间。雷达图会显示图像的时间戳，这是一个对原版硬件的改进，因为原始 WeatherStar 4000 并不显示这个信息。数据源是硬约束：NOAA API 只覆盖美国，所以项目无法用于国际地点。作者在 README 中承认这一点，并推荐了一个国际分支。
两种部署模式，性能与复杂度取舍
ws4kp 提供两种部署模式，这是理解项目运维方式的关键。服务器模式（Server Deployment）包含一个 Node.js 服务器，充当缓存代理，对多个客户端共享请求结果，并提供日志和可观测性。静态模式（Static Deployment）则完全在浏览器端运行，所有 API 请求直接从每个用户的浏览器发出，只依赖浏览器缓存。服务器模式适合在本地网络里服务多个客户端，能减少对 NOAA API 的重复请求。静态模式适合用 nginx 或 CDN 托管，无需服务器端脚本。两种模式的启动命令不同：服务器模式用 npm start，静态模式用 STATIC=1 npm start。生产环境需要先 npm run build，再用 DIST=1 启动。
快速启动与配置，环境变量控制一切
启动项目只需要 Node.js。克隆仓库后执行 npm install 和 npm start，浏览器访问 https://localhost:8080 即可。开发模式直接加载未压缩的 JS 模块，方便调试；生产模式通过 Webpack 打包成单个 bundle，减少请求数。配置通过环境变量完成，例如 Docker Compose 示例中，WSQS_latLonQuery 指定查询地点，WSQS_hazards 控制是否显示灾害警报，WSQS_current_weather 控制当前天气面板。这些变量对应 URL 中的 permalink 参数，意味着你可以通过 URL 直接分享特定地点的天气视图。Docker 用户可以直接拉取 ghcr.io/netbymatt/ws4kp 镜像，默认是静态模式，而 Dockerfile.server 则构建带缓存代理的服务器版本。
与原版和其他模拟器的差异
项目明确承认不是精确模拟，并指向 WS4000 Simulator 作为更准确的替代品。ws4kp 的改动包括：雷达图显示时间戳，新增 36 小时温度、云量和降水概率的逐小时图表，以及 24 小时逐小时预报，后者以旅行城市列表的风格呈现。这些改动是因为今天的预报信息比 90 年代更多或更少，作者认为有必要调整屏幕内容。这种取舍意味着，如果你追求像素级还原原始硬件的体验，ws4kp 会让你失望；但如果你只是想快速看到复古风格的天气界面，它反而更轻量。
限制与失败模式，哪些场景不适合
最大的限制是地理范围。NOAA API 只覆盖美国，项目代码与这个 API 紧密耦合，无法直接用于其他国家。README 明确说这是提供真实体验的必要条件，但这也意味着国际用户必须使用 ws4kp-international 分支。另一个限制是数据依赖：如果 api.weather.gov 出现故障或速率限制，项目会失去数据源。服务器模式通过缓存和请求去重来缓解，但静态模式下每个浏览器都直接请求，容易触发限制。此外，项目没有版本发布记录，也没有明确的更新周期，维护活跃度未知。对于需要稳定生产环境的用户，这一点需要谨慎评估。
维护与许可，MIT 带来的自由度
项目使用 MIT 许可证，允许自由使用、修改和分发，包括商业用途，只要保留版权声明。代码库强调开源和注释，使用 Gulp 和 Webpack 构建，SASS 管理样式，ESLint 保持代码风格一致。这些工程实践降低了维护门槛，但也意味着你需要 Node.js 工具链来构建和运行。没有自动化测试的提及，也没有 CI 配置的说明，这可能是维护上的短板。如果你计划长期使用，需要自己跟踪 NOAA API 的变化，因为项目没有明确的升级路径。
替代方案：WS4000 Simulator 与国际分支
如果你需要更精确的 WeatherStar 4000 模拟，WS4000 Simulator（taiganet.com）是官方推荐的替代品，它专注于硬件级别的准确复刻，但配置复杂度更高。如果你需要国际天气数据，ws4kp-international 分支是唯一选择，它由社区维护，修改了数据源适配非美国地区。这两个替代方案与 ws4kp 的核心差异在于目标：ws4kp 追求简单和现代可用性，WS4000 Simulator 追求历史准确性，国际分支则牺牲了原版的纯粹性以换取地理覆盖。选择哪个取决于你的优先级。
编辑结论
ws4kp 适合两类人：怀念 90 年代天气频道画面的美国用户，以及想学习现代 JavaScript 前端与 API 集成的新手程序员。不适合需要精确模拟 WeatherStar 4000 硬件行为的人，也不适合美国以外的用户，因为项目硬编码依赖 NOAA 的 API，境外无法获取数据。首次部署前，请确认你的服务器或浏览器能正常访问 api.weather.gov，并检查 NOAA 的速率限制是否满足你的使用场景。如果你需要国际天气数据，直接转向 ws4kp-international 分支，而不是修改主项目。最终判断：ws4kp 是一个诚实的怀旧项目，它明确承认自己不是完美模拟，而是追求简单可用，这一点在代码结构和文档中都体现得很清楚。
社区笔记