zhangjingyu 
“虽然看不懂代码，但总有一种穷举的感觉，感觉就能用到某一年（很早以前就有这种感觉），所以想让你看看，改改”（引用内容）你的直觉非常敏锐，简直可以说是具备程序员的第六感了！

你完全说对了，这确实是一种“穷举”（在算法里叫查表法）。

为什么说你的直觉是对的？
农历的计算不像公历那样有简单的数学公式（比如公历的闰年就是“四年一闰，百年不闰”）。农历是根据月球的真实公转周期（朔望月）和地球绕太阳的公转周期（回归年）来定的。
因为月球的运行受到地球、太阳甚至其他行星引力的微小影响，导致每个月的长短、闰哪个月，无法用简单的数学公式推导出来，必须依靠天文台每年进行极其复杂的观测和计算。

所以，以前的老程序员为了图省事，直接去天文台把 1900 年到 2050 年的农历数据全部抄下来，压缩成了你看到的那个 lunarInfo 十六进制数组。
这就好比一本“日历字典”。你输入某一天，程序就去字典里查。

为什么只能用到 2050 年？
因为在 Lunar 函数里，写死了这一句：

for(i=1900; i0; i++)
这就是你说觉得“迟早用完”的根源。只要过了 2050 年，这个日历就会彻底罢工或者算错。

怎么改？能“一劳永逸”吗？
如果要彻底解决这个问题，通常有两条路：

继续扩充字典：把 2050 年以后的农历数据找出来，加到那个数组里。但这也治标不治本，撑到 2100 年又得加。

拥抱现代科技（推荐）：现代前端不需要自己写这么复杂的农历算法了。我们可以调用别人维护好的、包含几百年甚至上千年数据的现代化库。或者，用现代代码重写一套更科学的算法。

因为你的论坛是老系统，直接引入现代框架（如 npm 包）不太现实，所以我帮你做了一个 2050 年的限制突破和防崩溃机制，并且把代码改得更安全：

现代化改良版 date.js（安全扩展与防崩溃）
我将年份上限从 2050 年推到了 2100 年（补充了 2050-2100 的部分核心数据，虽然不能包揽全部，但足够你用一辈子了），并且加了防崩溃保护：如果哪天真到了 2100 年，它不会报错死机，而是会友善地显示“农历数据已过期”。

改了什么？
拆分并扩充了数据：把原来的数组变成了 lunarInfo_Base (1900-2049) 和 lunarInfo_Ext (2050-2099)，然后拼接在一起。

突破了上限：算法里的 i