Project · 持续迭代

这是一个持续打磨出来的今日黄历项目。

项目目标不是简单复制一个黄历页面,而是把传统黄历信息做成结构清晰、可切换数据体系、可解释、可测试、可持续迭代的现代网页工具。

v2.1.6当前版本
69 次版本迭代
约 20h+累计开发时间
持续优化主要协作方式

这个项目是干嘛的

让黄历查询更清楚、更可验证

今日黄历用于查询指定日期的传统黄历信息,包括宜做事项、忌做事项、生肖冲煞、五行纳音、财神喜神福神方位、农历干支、时辰吉凶、时宜和时忌等。

页面支持“通用数据”和“协纪辨方书数据”两套体系切换,让用户既能看日常黄历风格的数据,也能参考更接近传统择吉体系的数据。

为什么做这个项目

把传统信息做成现代工具

普通黄历页面常见问题是数据来源不清、字段混在一起、时辰宜忌不够结构化、术语不容易理解。这个项目希望把黄历信息拆成清晰模块,同时保留必要的传统语境。

目前已加入选日子筛选、自然语言解析、月历视图、术语解释联动和情侣合日,让用户能从单日查询扩展到按事项、关系和月份做参考。

当前功能

当前功能

  • 黄历查询:查询指定日期的宜忌、吉凶、时辰、冲煞和方位。
  • 选日子:用一句话输入事项和条件,筛选吉日、平日和不推荐日期。
  • 月历视图:按月份查看每日吉凶分档,快速找到适合安排的日期。
  • 术语解释:把常见黄历术语翻译成大白话,点击即可查看说明。
  • 情侣合日:根据双方生日和关系场景,给出关系参考和适合推进的日期;生肖/星座支持自动识别或手选。

技术栈

简单、可部署、可测试

  • Vite + 原生 JavaScript + CSS。
  • Playwright 做桌面端和移动端烟测。
  • lunar-javascript 提供通用黄历数据。
  • lunisolar + advanced + theGods 提供协纪辨方书相关数据。
  • opencc-js 做协纪辨方书输出繁转简。
  • Node.js 服务负责静态资源和自然语言解析转发,敏感配置不放前端。
  • 外部 Web Worker 负责 选日子评分计算,主线程负责黄历数据预取和进度展示。
  • 公开页面只展示用户需要了解的功能、数据来源和版本变化,不展示内部运维细节。
  • 协作方式覆盖前端设计、全栈开发、质量检查和持续文档维护。

开发方式

按需求持续迭代

  • 围绕真实反馈拆解需求、实现功能、审查代码并完成测试。
  • 结合前端设计方法优化页面结构、交互和响应式体验。
  • 结合全栈开发方法梳理数据源、模块边界和构建配置。
  • 通过代码审查关注安全、可维护性和测试覆盖。
  • 每次重要变更都同步文档记录,并完成必要验证。

迭代过程

从 v1.0.0 到 v2.1.0

持续迭代

已经经历的关键阶段

  • v1.0.0:完成响应式黄历查询页初版,建立日期选择、宜忌、吉凶评分和基础黄历信息展示。
  • v1.1.0:改用本地黄历数据体系,补齐生肖、冲煞、五行纳音、方位和时辰宜忌等结构化内容。
  • v1.2.0:上线通用数据 / 协纪辨方书双数据源切换,让日常查询和传统择吉参考可以按需切换。
  • v1.3.0:补齐黄历解说、更新日志和项目说明等内容页,让术语、版本和项目背景更清楚。
  • v1.4.0:上线选日子页,支持按事项、时间范围和生肖综合筛选,并按吉日 / 平日 / 凶日分组展示。
  • v1.5.0:接入自然语言解析和长期审核机制,支持一句话填写择日条件,并持续扩展现代高频事项识别。
  • v1.6.0:新增月历视图并持续优化月度浏览、移动端排版、加载进度、日期缓存和术语解释联动。
  • v1.7.0:情侣合日作为独立大版本上线,长期匹配参考与推荐日期拆分展示,并持续优化评分维度、日期分层、输入区排版和分析速度。
  • v1.8.0:优化微信 H5 分享封面、全站分享预览、移动端安全区和静态资源缓存;清理旧版隐藏分享入口,并评估通过预生成黄历数据继续提升选日子、情侣合日和月历速度。
  • v2.0.0:性能架构升级,选日子、情侣合日和月历优先读取预生成黄历数据,功能页空闲预热协纪查询,重复筛选和月份切换更快。
  • v2.1.0:新版选日子页面上线,结果先按吉日 / 平日 / 凶日分组展示,再升级为先生建议体验,包含等待态、断语、建议排版、首选/备选日期、推荐时辰和生辰边界校准。

后续计划

  • 继续优化事项识别、词典覆盖和边界表达,让一句话输入更稳定。
  • 继续完善选日子、情侣合日和月历的移动端体验。
  • 扩充黄历术语解释库,并和页面实际出现的宜忌词联动。
  • 评估个人起名、公司起名,以及爱情、合作、事业、合同、开公司等关系匹配能力。
  • 长期评估微信小程序、安卓 APP、iOS APP 和华为生态 APP 等多端产品形态。
  • 继续完善数据来源说明和两套数据体系差异解释。