用 Java 把干支历法算清楚:从节气切年到可读摘要
最近在做一个个人侧项目:把「公历生日 → 四柱干支 → 可读说明」这条链路跑通。
博客园里命理文很多,这篇只写**工程实现**,不讨论吉凶论断。
为什么要自己做
市面上同类工具不少,常见问题是:
-
前端广告重,核心计算过程不透明
-
结果一大段套话,看不出「字段从哪来」
-
想二次开发时,干支/十神/藏干往往揉在一坨里
我更想把流程拆成可测的层:先算准结构,再生成文案。
技术栈
-
后端:Java + Spring Boot,SQLite 存业务数据
-
前端:Vue
-
部署:单体服务,静态资源打进后端(省事)
侧项目阶段优先「能维护、好排查」,而不是一上来微服务。
分层:别把「算」和「说」耦死
我把链路拆成三层:
- **历法计算层**
输入:公历日期时间(可选真太阳时修正)
输出:年/月/日/时柱、藏干、十神等**结构化结果**
这里只做确定性计算,不写营销文案。
- **证据/模式层**
在结构上找可解释的组合(例如某些十神分布、干支关系),产出「发现列表」而不是结论句。
- **表达层**
把发现翻译成白话摘要。这一层可以换语气、换语言,但不回写计算。
好处很直接:
-
单元测试主要锁在第 1、2 层(输入输出可断言)
-
改文案不会把排盘算乱
-
以后要出英文版/更短摘要,只动表达层
两个容易踩坑的点
1. 月柱不是「公历月」
干支月以**节气**切分,不是 1 号换月。
实现时要有可靠的节气时刻表(或库),并明确时区(我按业务用东八区)。
2. 「可读」
摘要层尽量写:
-
这个字段叫什么、从哪根柱来
-
常见文化语境里怎么解释(科普口径)
少写:
- 「你一定会...」「务必...」这类断言
产品侧我把它定位成**传统文化/历法科普工具**,完整报告也是「更细的说明」。
前端交互上的取舍
免费区先给结构化结果 + 短摘要,降低「必须注册才能看一眼」的摩擦。
需要更长说明时再解锁------这是产品选择,和计算层无关;计算在服务端一次完成,解锁只是展示权限。
还在迭代的地方
-
合盘:两人结构对比时,评分与文案如何分开
-
真太阳时:经度修正对时柱边界的影响说明写清楚
-
埋点:来源(`?from=`)与 Referer,方便看哪类外链有效(技术站引流波动大)
小结
如果也想做「传统文化 + 工程」类侧项目,建议先把**可测试的计算内核**立住,再谈展示和变现。
算不准,文案再顺也只是噪音。
项目在线试用(个人站点,科普向):
https://www.dousnl.com/go?from=cnblogs
欢迎对节气切月、十神映射、分层边界拍砖。纯技术讨论优先。