简介：这份JAVA万年历源码面向Java初学者与课程设计实践者，围绕日期时间处理、Swing图形界面与事件驱动编程展开，可用于完成万年历记事本类课程设计或巩固Java基础。压缩包内共1个doc文件，约317KB，以课程设计报告形式呈现，涵盖总体设计、类与方法说明、运行效果展示及完整源代码，便于对照理解calendar类的成员变量、方法职责与界面布局思路。内容涉及Calendar与java.time日期操作、JComboBox月份选择、JButton事件响应、ActionListener与MouseListener接口实现、文件读写保存日记、闰年判断与月份天数计算等知识点，并附有保存、删除确认等交互细节说明。目前已有185人学习，适合需要参考完整项目结构、梳理GUI事件处理流程或准备Java课程设计报告的学习者使用。

1. 万年历记事本：为什么一个 42 格数组就能装下整个月历

打开一份十多年前的 Java 课程设计源码，最扎眼的往往不是界面多简陋，而是那个JTextField ShowDays[] = new JTextField[42]。42 个格子，固定不变，既不是 28 也不是 31，更不是 35。这个数字不是随手拍的，它背后藏着月历渲染最核心的一条约束：任何一个月，最多只需要 6 行 × 7 列就能完整铺下。一个月最多 31 天，如果 1 号恰好落在周六，那么前 6 个格子空着，31 天占掉第 7 到第 37 格，最后还剩 5 格空位——42 是「7 的倍数里刚好能覆盖最坏情况」的最小值。搞懂这个数字，就搞懂了万年历这类程序的第一层设计动机：日历不是逐日算出来的，而是先算出一个偏移量，再把数字往固定槽位里填。这份 JAVA 万年历源码把「日期计算」和「界面渲染」彻底拆成两条线，前者只回答两个问题——这个月第一天是星期几、这个月有几天，后者只负责把 1 到 N 依次塞进从偏移量开始的格子。理解了这条分界线，后面所有的闰年判断、跨月翻页、记事本按日期存文件，都只是这条主线上的自然延伸。

2. 日期计算：GetStartDay 为什么敢从一个负数年份开始累加

2.1 从 0000 年到目标月的天数累加模型

这份源码里最容易被忽略、也最能体现「课程设计式实现」的一段，是GetTotalNumOfDays和GetStartDay的配合。它没有用java.util.Calendar去查某天是星期几，而是自己从「公元 0 年 1 月 1 日」开始，把每一年的天数一年一年加过来，再把目标月之前的每个月天数加上去，最后对 7 取模得到星期偏移。核心逻辑如下：

public long GetTotalNumOfDays(int year, int month) { long total = 0; // 从 -32767 年开始逐年累加，负数年份也照算不误 for (int i = -32767; i < year; i++) { if (IsLeapYear(i)) total = total + 366; else total = total + 365; } // 再加上本年 1 月到目标月前一个月的天数 for (int i = 1; i < month; i++) total = total + GetNumOfDaysInMonth(year, i); return total; } public int GetStartDay(int year, int month) { int startday0001 = -32768; // 基准偏移，把取模结果拉回 0..6 long totalnumofdays = GetTotalNumOfDays(year, month); return (int) ((totalnumofdays + startday0001) % 7); }

这段代码的机制可以拆成三层。第一层是年累加：循环变量从-32767起步，意味着它把「公元前」的年份也当成普通整数参与闰年判断，这在数学上并不严谨（历法本身经历过多次改革），但对一个课程设计来说，只要保证同一个年份算出来的结果稳定一致就够了。第二层是月累加：GetNumOfDaysInMonth负责返回 28/29/30/31，2 月走闰年分支。第三层是取模对齐：startday0001 = -32768这个常量看着像玄学，本质是一个校准值，让「公元 0 年 1 月 1 日」经过(total + (-32768)) % 7之后落在程序约定的星期编号上。-32768恰好是short的最小值，我一般会这么理解：作者可能是从某个short类型的边界值顺手拿来当偏移，只要最终% 7的结果和week[]数组下标对得上，这个常量取多少都能通过调整基准来凑。

提示：这种「从固定纪元累加再取模」的算法，时间复杂度是 O(年数)，年份越大越慢。现代实现会改用蔡勒公式或直接调LocalDate.getDayOfWeek()，但它的优点是逻辑完全自包含，不依赖任何库的历法实现，非常适合拿来理解「星期几到底是怎么算出来的」。

2.2 闰年判断：为什么是 400 和 100 两个门槛

IsLeapYear只有一行判断，却是整个日期计算的地基：

public boolean IsLeapYear(int year) { // 能被 400 整除，或能被 4 整除但不能被 100 整除 if ((year % 400 == 0) || (year % 4 == 0 && year % 100 != 0)) return true; else return false; }

这条规则的动机来自格里高利历对儒略历的修正：地球公转周期约 365.2422 天，如果每 4 年补一天，每年平均 365.25 天，一百年就会多出约 0.78 天；于是每 100 年取消一次闰年，把误差压到 0.01 天级别；再每 400 年恢复一次，进一步逼近真实值。代码里% 400放在前面、% 4 && % 100 != 0放在后面，顺序不影响结果，但先判 400 能让 2000 年这类整百年份少走一次与运算。GetNumOfDaysInMonth则把 1、3、5、7、8、10、12 月硬编码为 31 天，4、6、9、11 月为 30 天，2 月交给闰年判断，最后return 0兜底非法月份。这种写法在参数校验上是有漏洞的——传进来 month=13 会静默返回 0，而不是抛异常，后面PrintMonthBody拿到 0 天就会渲染出一个空月。血泪经验是：凡是「返回 0 表示出错」的函数，调用方一定要显式检查，否则错误会一路静默传播到界面上。

2.3 偏移量到格子：PrintMonthBody 的双参数与三参数重载

真正把「算出来的偏移」变成「屏幕上的数字」的是PrintMonthBody。源码里有两个重载版本，一个接收(startday, dayinmonth)，一个接收(startday, dayinmonth, day)，后者多一个day用来高亮当天：

public void PrintMonthBody(int startday, int dayinmonth, int day) { // 从 startday 开始，依次填入 1..dayinmonth for (int i = startday, n = 1; i < startday + dayinmonth; i++) { ShowDays[i].setText("" + n); ShowDays[i].setHorizontalAlignment(0); if (n == day) { // 当天高亮：绿色大字 ShowDays[i].setForeground(Color.green); ShowDays[i].setFont(new Font("TimesRoman", Font.BOLD, 20)); ShowDays[i].setBackground(Color.DARK_GRAY); } else { ShowDays[i].setFont(new Font("TimesRoman", Font.BOLD, 12)); ShowDays[i].setForeground(Color.white); ShowDays[i].setBackground(Color.DARK_GRAY); } n++; } // 前置空格子清空 for (int i = 0; i < startday; i++) { ShowDays[i].setText(""); ShowDays[i].setBackground(Color.DARK_GRAY); } // 后置空格子清空 for (int i = startday + dayinmonth; i < 42; i++) { ShowDays[i].setText(""); ShowDays[i].setBackground(Color.DARK_GRAY); } }

这里有个容易被忽略的细节：每次重绘都必须把 42 个格子全部处理一遍。前startday个清空、中间填数字、后面42 - startday - dayinmonth个清空，三段合起来正好覆盖 0 到 41。如果只填数字不清空，翻到 2 月时上个月 31 号残留的数字就会留在末尾格子里，这是日历类程序最经典的翻车点之一。作者用两个独立的 for 循环做清空，而不是在填数字的循环里顺手处理，说明他踩过这个坑——先保证「所有格子状态归零」，再保证「该有数字的格子有数字」，顺序不能反。

3. 界面与事件：Swing 的布局树怎么撑起一个双栏日历

3.1 BorderLayout 套 GridLayout：左日历右记事本的结构

整个窗口用JSplitPane横向切开，左边是日历面板LeftPane，右边是记事本面板RightPane。LeftPane内部又是三层BorderLayout：北边LeftNorth放查询区和翻月按钮，中间LeftCenter放 7×7 网格，南边放「回到今天」按钮。LeftCenter用GridLayout(7, 7)，第一行是week[]里的 SUN 到 SAT 七个标题标签，剩下 42 个格子就是ShowDays数组。这种「外层 BorderLayout 定方位、内层 GridLayout 定矩阵」的组合，是 Swing 里做日历最省事的布局思路：

LeftCenter.setLayout(new GridLayout(7, 7)); for (int i = 0; i < 7; i++) { // 第一行：星期标题 TopBarTitle[i] = new JLabel(week[i]); TopBarTitle[i].setHorizontalAlignment(0); LeftCenter.add(TopBarTitle[i]); } for (int i = 0; i < 42; i++) { // 后 42 格：日期槽位 ShowDays[i] = new JTextField(); ShowDays[i].addMouseListener(this); // 每个格子都能点，点了切到那天 ShowDays[i].setEditable(false); LeftCenter.add(ShowDays[i]); }

GridLayout(7, 7)会强制 49 个组件等宽等高，所以 42 个日期格子和 7 个标题格子视觉上完全对齐，不需要手动算坐标。代价是窗口缩放时格子会跟着拉伸，字体不会自动适配，窗口拉得太小数字就会挤在一起。这是布局管理器的取舍：用约束换省心，用自适应换精确控制。ShowDays用JTextField而不是JLabel，是因为JTextField自带背景色和边框，改setBackground就能做出「深色格子 + 白色数字」的效果，比给JLabel设setOpaque(true)再调边框要直接。

3.2 ActionListener 与 MouseListener：一个类同时接两种事件

calendar类直接implements ActionListener, MouseListener，所有按钮和格子的事件都收口到同一个类里。按钮通过setActionCommand打标签区分：

PriorMonth.setActionCommand("prior"); NextMonth.setActionCommand("next"); SouthSave.setActionCommand("Save"); SouthDelete.setActionCommand("Delete");

然后在actionPerformed里用e.getActionCommand()分支处理。这种「一个监听器管所有按钮」的写法在课程设计里很常见，好处是不用为每个按钮写匿名内部类，坏处是方法会越写越长，分支一多就难维护。更现代的做法是每个按钮配一个 lambda，但 2012 年的 Java 还没有 lambda，匿名内部类又太啰嗦，所以集中式监听是当时的主流选择。鼠标事件则挂在 42 个日期格子上，mouseClicked里根据被点中的格子反推是哪一天，然后更新day、刷新右侧记事本标题、触发ReadRecord去读那天的日记文件。这里的关键是格子下标和日期的映射关系：ShowDays[i]里的文本就是日期数字，点中后直接Integer.parseInt(ShowDays[i].getText())就能拿到 day，不需要额外维护一张下标到日期的表。

3.3 记事本的文件命名：key 是怎么拼出来的

右侧记事本的核心是一个字符串key，格式是年_月缩写_日，比如2012_Jun_25。这个 key 在构造函数里初始化一次，之后每次切换日期都要重新拼：

key = year + "_" + SwitchMonth + "_" + day;

SwitchMonth是SwitchMonth(int month)方法根据月份数字映射出来的三字母缩写（Jan、Feb……Dec）。用缩写而不是数字，是为了让文件名可读，但这也埋了个坑：源码里case 10写成了SwitchMonth = "Qct"，把 Oct 拼错了。这个错拼不影响程序运行，因为读写用的是同一个 key，但它说明凡是「显示用字符串」和「存储用字符串」共用一个变量，拼写错误就会同时污染界面和文件名。保存时WriteRecord先new File("Diary").mkdir()确保目录存在，再拼Diary\\key.txt用FileWriter逐字符写入；读取时ReadRecord先判断文件是否存在，存在就弹确认框问要不要读，用户点「是」才把内容灌进CenterText。删除则更粗暴，直接Runtime.getRuntime().exec("cmd /c del " + filepath)调系统命令删文件——这在 Windows 上能跑，换到别的平台就翻车，属于典型的「课程设计只保证演示环境可用」。

4. 避坑与排查：这份源码里最容易翻车的五个点

4.1 翻月后格子残留上个月数字

现象：从 1 月翻到 2 月，末尾几个格子还显示 30、31。原因：PrintMonthBody只填了startday到startday + dayinmonth之间的格子，没有清空尾部。解决：确认两个清空循环都在，且上界是 42 而不是startday + dayinmonth；如果自己改代码，务必在填数字之前先把 42 个格子全部setText("")一遍。

4.2 读取日记时文件不存在直接抛异常

现象：点某一天，控制台报FileNotFoundException，界面没反应。原因：ReadRecord里new FileReader(myfile)写在if (myfile.exists())判断之前，文件不存在时构造FileReader就已经抛异常了。解决：把FileReader的创建挪进exists()分支内部，或者先判断再 new；catch 块里给CenterText设一句「今天还没有记录」的提示，而不是静默吞掉。

4.3 删除文件依赖 cmd 命令导致跨平台失效

现象：在非 Windows 环境点删除，弹「删除成功」但文件还在。原因：Runtime.exec("cmd /c del ...")只在 Windows 命令解释器下有效，其他平台要么找不到 cmd，要么 del 不是删除命令。解决：改用myfile.delete()，返回值是 boolean，根据返回值决定弹成功还是失败；路径分隔符也别硬编码\\，用File.separator或直接new File(dir, name)。

4.4 年份输入非数字导致 NumberFormatException

现象：在年份输入框里敲字母再点查询，程序抛异常。原因：AboutActionListenerWay里直接Integer.parseInt(YearText.getText())，没有 try-catch。解决：包一层 try-catch，捕获NumberFormatException后弹提示框让用户重输；更稳的做法是给YearText加InputVerifier，在失焦时就校验。

4.5 42 格数组越界

现象：某些月份渲染时抛ArrayIndexOutOfBoundsException。原因：如果GetStartDay返回负数（取模结果为负），for (int i = startday; ...)的起始下标就是负的。Java 的%对负数返回负余数，(total + startday0001) % 7在 total 较小时可能为负。解决：取模后加 7 再模 7，写成((total + startday0001) % 7 + 7) % 7，保证结果落在 0 到 6。

5. 设计取舍：为什么「自己算日期」在当年是合理选择

把这份源码放到今天的语境里看，最值得讨论的不是它用了 Swing 还是 AWT，而是它为什么选择手写GetTotalNumOfDays而不是调Calendar。2012 年的 Java 里java.util.Calendar已经存在，Calendar.get(Calendar.DAY_OF_WEEK)一行就能拿到星期几，但课程设计的评分点往往落在「你有没有理解算法」而不是「你会不会调 API」。手写累加模型的价值在于：它把「星期几」这个看似神秘的东西还原成「从某个起点数了多少天，再对 7 取余」，一旦这个映射建立起来，闰年、月份天数、跨年翻页全都变成同一套算术的推论。这种「先造轮子再理解轮子」的路径，和直接调库的路径，学到的东西完全不一样。

但取舍也很明显。手写模型的性能是 O(年数)，查 2012 年要循环两万多次，查 9999 年要循环三万多次，虽然对桌面程序来说这点开销可以忽略，但它暴露了一个设计问题：基准点和偏移量是硬编码的魔法数。-32768这个值没有任何注释说明它从哪来，换一个人接手根本不敢动。如果重写，我会把「公元 0 年 1 月 1 日是星期几」定义成一个具名常量，把取模统一成Math.floorMod，让负数和正数走同一条路径。另一个取舍是文件存储：用年_月缩写_日.txt做文件名，好处是直观、不用数据库，坏处是月份缩写依赖SwitchMonth的映射，一旦映射表改了就找不到旧文件。更稳的做法是用年-月-日的零填充数字格式，排序和解析都更可靠。

我一般会这么理解这份源码的定位：它不是拿来直接上生产的，而是一份「把日历的每个环节都摊开给你看」的教学样本。你可以在它上面看到偏移量怎么算、格子怎么填、文件怎么按日期落盘、事件怎么从按钮流到数据层，这些环节在现代框架里都被封装掉了，反而很难看清。从那以后我每次碰日期相关的需求，都会先把「起点、偏移、取模」这三件事在纸上画一遍，再决定用库还是自己算——这个习惯就是被这类源码逼出来的。希望帮到你。

本文还有配套的精品资源，点击获取