简介这份资源是一套基于C#与WinForms开发的日程提醒器完整项目源码面向具备一定C#基础、希望借助桌面应用实例巩固.NET开发技能的开发者。项目围绕事件添加、列表查看、提醒开关、倒计时显示与弹窗通知等核心功能展开涵盖界面设计、数据结构定义、按钮事件处理、Timer定时检查及MessageBox通知等典型实现环节适合作为课程设计或练手参考。压缩包共47个文件约317KB以cs源码文件为主辅以resx与resources界面资源、exe可执行程序、config配置、dll依赖及sln解决方案等另含数据库相关文件结构完整可直接在Visual Studio中打开研读。目前已有399人学习下载。读者可从中获取登录注册、事件管理等多窗体的组织方式理解定时器驱动倒计时与提醒触发的完整链路并借鉴异常处理与模块化设计的实践思路用于二次开发或功能扩展。1. 日程提醒器不是玩具一个 WinForm 倒计时项目能撑起多少真实需求很多人对 WinForm 的印象还停留在“拖控件、点按钮”的课程作业层面直到某天被一个真实诉求打脸桌面角落需要一个能盯着截止日期、按天甚至按小时倒计时、到点弹窗加声音提醒的小工具而且不能依赖浏览器、不能联网、开机就得在。这类需求用网页做反而重用 WinForm 做刚刚好——常驻托盘、定时器驱动、本地存储、零依赖运行一套下来几百行代码就能闭环。这个 C# WinForm 日程提醒器项目核心就是围绕“日期 倒计时 提醒触发”三件事展开维护一组带截止时间的日程条目用定时器周期性刷新剩余时间命中阈值时触发视觉与声音提醒并把数据落到本地文件避免重启丢失。它适合两类人一是想找一个结构完整、能直接改造成自己工作台小助手的 C# 练手项目二是手上确实有一堆截止日期要盯、又不想装一堆臃肿软件的从业者。下面按“它怎么组织 → 怎么跑起来 → 参数怎么调 → 哪里会翻车”的顺序拆。2. 拆开项目结构日程数据模型与倒计时刷新机制2.1 日程条目该存哪些字段为什么不是越少越好一个提醒器最容易犯的错是把日程简化成“标题 时间”两个字段结果用两天就发现不够没法标记已完成、没法区分轻重缓急、没法知道这条提醒到底响过没有。合格的日程模型至少要覆盖标识、内容、时间、状态四类信息。常见做法是定义一个ScheduleItem类字段大致如下字段类型作用备注Idstring/Guid唯一标识增删改查的锚点Titlestring日程标题显示在列表主列DueTimeDateTime截止时间倒计时基准Priorityint/enum优先级影响排序与颜色IsCompletedbool是否完成完成后不再提醒HasNotifiedbool是否已提醒防止重复弹窗Remarkstring备注可选存细节DueTime用DateTime而不是字符串是因为倒计时计算要频繁做时间差字符串每次都得解析既慢又容易在格式上翻车。HasNotified这个字段看着不起眼却是避免“到点后每秒弹一次窗”的关键——没有它定时器每刷新一次就可能重复触发。IsCompleted则让列表可以区分“待办”和“已归档”不然一堆过期条目会把界面撑爆。数据持久化上这个体量的项目没必要上数据库序列化成 JSON 存本地文件就够。用System.Text.Json或Newtonsoft.Json都行前者是 .NET 内置少一个依赖。存储路径建议放在Environment.GetFolderPath(SpecialFolder.ApplicationData)下的自定义子目录而不是程序目录——程序目录在部分系统位置可能没有写权限这是新手最常踩的坑之一。2.2 定时器怎么选WinForms Timer 与刷新频率的取舍倒计时刷新的核心是一个定时器。WinForm 里最顺手的是System.Windows.Forms.Timer它的回调在 UI 线程上执行改控件文本不需要Invoke对这个小工具来说是最省事的选择。代价是精度一般间隔设得太小会拖累界面设得太大倒计时看起来会“跳秒”。我一般把刷新间隔定在 500ms 到 1000ms 之间。1000ms 足够让“剩余 X 天 X 小时 X 分 X 秒”每秒变化一次又不会给 UI 线程造成明显压力。如果只显示到“天”或“小时”间隔甚至可以放到 5 秒甚至 30 秒反正显示粒度粗没必要高频刷新。这里有个反直觉的点刷新频率不是越高越好倒计时显示精度和定时器频率要匹配显示到秒才需要秒级刷新显示到天却每秒刷新纯属浪费。刷新逻辑本身要写成“从当前时间重新算差值”而不是“每次减一”。后者在系统休眠、定时器被阻塞时会累积误差醒来后倒计时就偏了。正确姿势是每次 Tick 都用DueTime - DateTime.Now重新计算这样即使中间卡顿恢复后显示依然准确。示例private void timer_Tick(object sender, EventArgs e) { var now DateTime.Now; foreach (var item in scheduleList.Where(x !x.IsCompleted)) { // 每次都基于当前时间重算避免累积误差 var span item.DueTime - now; if (span.TotalSeconds 0) { item.DisplayText 已到期; // 命中提醒条件且尚未提醒过才触发 if (!item.HasNotified) { item.HasNotified true; TriggerReminder(item); } } else { item.DisplayText FormatSpan(span); // 格式化为 X天X时X分X秒 } } RefreshListView(); // 统一刷新界面 }这段代码有两个关键点一是span.TotalSeconds 0作为到期判定比直接比较DateTime更直观二是HasNotified的检查放在触发之前保证一条日程只提醒一次。FormatSpan是自定义格式化方法把TimeSpan拼成中文可读文本注意天数要用span.Days而不是span.TotalDays取整否则跨月会算错。2.3 界面与数据的绑定方式ListView 还是 DataGridView列表展示有两条路ListView轻量、定制灵活适合列不多的场景DataGridView自带编辑、排序、列宽调整适合字段多、要就地编辑的场景。日程提醒器字段在六七个左右又需要按优先级着色、按到期时间排序ListView配合OwnerDraw或简单的ForeColor设置就够用代码量更小。如果想让用户直接在表格里改标题和时间那就选DataGridView绑定BindingListScheduleItem后增删会自动反映到界面省掉手动刷新的麻烦。不管选哪个都要注意“数据源”和“界面”分离所有增删改先操作内存里的ListScheduleItem再统一刷新控件而不是直接往控件里塞字符串。这样保存、排序、过滤都只针对一份数据逻辑清晰也不容易出现界面和数据对不上的黑匣子状态。3. 从零跑起来环境、入口与提醒触发的完整链路3.1 环境准备与项目骨架搭建这个项目对环境的门槛很低但版本选错会带来不必要的麻烦。建议用 Visual Studio 2022 或更高版本创建“Windows 窗体应用.NET”项目目标框架选 .NET 6/7/8 的net6.0-windows这类带-windows后缀的 TFM才能用 WinForm。如果选 .NET Framework 4.7.2/4.8 也能跑但 JSON 序列化要额外引包新项目没必要。创建后目录结构大致是Program.cs作为入口MainForm.cs主窗体再按职责拆出ScheduleItem.cs模型、ScheduleStore.cs读写 JSON、ReminderService.cs提醒逻辑。小项目不必过度分层但模型和存储至少要和窗体分开否则后面想加“导入导出”功能时逻辑全缠在按钮事件里改起来很痛苦。Program.cs里除了默认的Application.Run(new MainForm())如果要做托盘常驻还要处理单实例和退出行为。常见做法是用Mutex做单实例检查避免用户重复双击开出多个提醒器互相弹窗[STAThread] static void Main() { // 单实例已存在同名 Mutex 则直接退出避免多开重复提醒 using var mutex new Mutex(true, ScheduleReminder_SingleInstance, out bool createdNew); if (!createdNew) return; ApplicationConfiguration.Initialize(); Application.Run(new MainForm()); }Mutex的名字随便起但要全局唯一createdNew为 false 说明已有实例在跑。注意using保证退出时释放否则下次启动会被自己挡住。3.2 新增日程与时间输入的校验新增日程的入口通常是一个“添加”按钮弹出的小对话框里面放标题输入框、DateTimePicker选截止时间、优先级下拉。这里最容易翻车的是时间校验用户可能选一个过去的时间或者标题留空。合格的做法是在确认时统一校验而不是等保存后再报错。private bool ValidateInput(string title, DateTime due) { if (string.IsNullOrWhiteSpace(title)) { MessageBox.Show(标题不能为空); return false; } // 允许少量宽限避免用户选“当前这一分钟”被误判为过去 if (due DateTime.Now.AddMinutes(-1)) { MessageBox.Show(截止时间不能早于当前时间); return false; } return true; }DateTimePicker默认可能带秒展示时建议把Format设为Custom、CustomFormat设为yyyy-MM-dd HH:mm减少用户输入歧义。校验通过后再构造ScheduleItem、加入列表、调用存储层保存最后刷新界面。顺序别乱先落内存再落盘落盘失败要回滚或提示不然界面显示成功、重启后数据没了这种“假成功”最坑人。3.3 提醒触发弹窗、托盘气泡与声音的组合提醒触发是整条链路的高潮也是最容易做得粗糙的地方。只弹一个MessageBox的问题在于它会阻塞 UI 线程用户不点确定后面的定时器刷新全停倒计时就卡住了。所以提醒要么用非模态窗体要么用托盘气泡NotifyIcon.ShowBalloonTip后者不阻塞、不抢焦点体验更好。声音提醒用System.Media.SystemSounds里的系统音最省事不需要额外音频文件private void TriggerReminder(ScheduleItem item) { // 托盘气泡提醒不阻塞 UI 线程 notifyIcon.ShowBalloonTip(5000, 日程到期, item.Title, ToolTipIcon.Warning); // 系统提示音避免依赖外部 wav 文件 SystemSounds.Exclamation.Play(); // 可选把该条目在列表中高亮方便用户定位 HighlightItem(item); }ShowBalloonTip的时长参数在部分系统上会被系统设置覆盖不要指望它精确到毫秒。SystemSounds依赖系统声音方案如果用户静音了系统音提醒就只剩视觉部分——这是预期行为不是 bug但要在文档或界面上让用户知道否则会被当成“提醒没响”来报障。更稳妥的做法是提供一个“提醒方式”设置项让用户勾选气泡、声音、弹窗中的哪几种。3.4 数据持久化JSON 读写与异常兜底存储层要做的事就三件启动时读、变更时写、异常时不崩。读的时候文件可能不存在首次运行、可能损坏手动改坏或写入中断这两种情况都要兜住不能让程序一启动就抛异常退出。public static ListScheduleItem Load(string path) { try { if (!File.Exists(path)) return new ListScheduleItem(); var json File.ReadAllText(path); return JsonSerializer.DeserializeListScheduleItem(json) ?? new ListScheduleItem(); } catch (Exception ex) { // 读失败时备份坏文件返回空列表保证程序能启动 File.Copy(path, path .bak, overwrite: true); MessageBox.Show($日程文件读取失败已备份原文件{ex.Message}); return new ListScheduleItem(); } }写的时候建议先写临时文件再替换避免写到一半断电导致原文件损坏public static void Save(string path, ListScheduleItem items) { var tmp path .tmp; var json JsonSerializer.Serialize(items, new JsonSerializerOptions { WriteIndented true }); File.WriteAllText(tmp, json); File.Copy(tmp, path, overwrite: true); // 原子替换的简化写法 File.Delete(tmp); }WriteIndented true让 JSON 可读方便排查问题生产环境如果条目很多可以关掉省空间。File.Copy覆盖不是严格原子操作但对这个体量的工具足够真要严谨可以用File.Replace。4. 参数与边界倒计时显示、排序和性能的几个关键设定4.1 倒计时文本格式化天、时、分、秒怎么拼才不别扭TimeSpan直接ToString()出来是1.02:03:04这种格式普通用户看不懂。要自己拼成“1 天 2 小时 3 分 4 秒”并且按剩余量动态省略高位剩余不到一天就不显示“天”不到一小时就不显示“小时”。这样列表看起来才清爽。private string FormatSpan(TimeSpan span) { if (span.TotalDays 1) return ${(int)span.TotalDays} 天 {span.Hours} 时 {span.Minutes} 分; if (span.TotalHours 1) return ${span.Hours} 时 {span.Minutes} 分 {span.Seconds} 秒; return ${span.Minutes} 分 {span.Seconds} 秒; }注意span.Days和(int)span.TotalDays的区别前者是“去掉整周后的天数”TimeSpan的Days分量最大到 6 就进位到TotalDays的周部分直接用span.Days在超过 7 天时会显示错误。这是很多人第一次写倒计时都会踩的坑血泪经验。4.2 排序与优先级到期时间优先还是优先级优先列表排序策略直接影响可用性。纯按到期时间排高优先级的急事可能被一堆远期低优先级条目压在下面纯按优先级排又会让最近到期的条目沉底。常见做法是“未完成在前、已完成在后未完成内部先按优先级降序、再按到期时间升序”这样既突出重要事项又保证同级里最近的先看到。用 LINQ 表达就是var ordered scheduleList .OrderBy(x x.IsCompleted) // 未完成(false)排前面 .ThenByDescending(x x.Priority) // 高优先级在前 .ThenBy(x x.DueTime) // 同级按到期时间升序 .ToList();OrderBy对 bool 排序时 false 在前正好符合“未完成优先”。如果想让已完成的也按完成时间倒序可以再加一层ThenByDescending。排序每次刷新都重算会有开销条目少无所谓上百条时建议只在数据变更时排序、缓存结果。4.3 常驻托盘与开机自启的边界日程提醒器要“一直在”就得考虑最小化到托盘而不是关闭退出。做法是拦截窗体的FormClosing事件当关闭原因是用户点 X 时取消关闭、改为Hide()同时NotifyIcon保持可见双击托盘图标再Show()回来。真正退出走托盘右键菜单里的“退出”项用一个标志位区分。开机自启有两条路写注册表Run键或把快捷方式放进启动文件夹。前者更“正规”但涉及注册表写入部分安全软件会拦后者简单直观用户也能自己管理。我一般用启动文件夹方案代码里用Environment.GetFolderPath(SpecialFolder.Startup)拼路径创建快捷方式失败就提示用户手动添加不硬来。这里要提醒一句自启功能默认关闭让用户主动勾选别默认开启否则容易被当成流氓软件。5. 避坑与排查这类小工具最容易翻车的五个地方5.1 到点后弹窗刷屏现象日程到期后每隔一秒弹一次提示关都关不完。原因定时器每次 Tick 都判断“已到期”就触发提醒没有记录“已提醒”状态。解决在ScheduleItem上加HasNotified字段触发前置为 true 并持久化或者把已提醒条目移出待提醒集合。注意持久化这一步不能省否则重启后又会重弹一遍。5.2 系统休眠唤醒后倒计时错乱现象合盖休眠几小时再打开倒计时显示的时间比实际剩余少了一大截或者直接显示已到期。原因用了“每次 Tick 减一”的累加式计时休眠期间定时器不触发醒来后差值没补上。解决改成每次 Tick 都用DueTime - DateTime.Now重算天然免疫休眠和卡顿。这个改法几乎零成本但很多人一开始图省事写成减法后面排查半天。5.3 数据文件写入后重启丢失现象界面上新增了日程关掉再开就没了。原因只更新了内存列表没调用保存或者保存路径写到了程序目录而程序装在无写权限的位置写入静默失败。解决所有变更操作后统一走Save存储路径改用ApplicationData目录保存时捕获异常并提示别让失败无声无息。5.4 托盘图标退出后残留现象点了退出托盘区还留着一个图标鼠标划过才消失。原因NotifyIcon没有Dispose或者窗体关闭流程里没先隐藏图标。解决在退出逻辑里先notifyIcon.Visible false再notifyIcon.Dispose()最后Application.Exit()。顺序反了就会出现“幽灵图标”。5.5 多开导致重复提醒现象同一条日程弹了两次提醒。原因用户重复双击启动了多个实例每个实例都有自己的定时器和托盘图标。解决入口处用Mutex做单实例检查第二个实例直接退出并激活已有窗口可通过命名管道或窗口消息实现简单场景直接退出也够用。6. 进阶玩法把提醒器改成可配置的提醒策略引擎基础版跑通后真正拉开差距的是“提醒策略”这一层。默认的“到期那一刻提醒一次”太单薄实际使用中更想要的是“提前 3 天提醒一次、提前 1 天再提醒一次、到期当天每小时提醒”。这不需要推翻重来只要在模型里加一个“提醒规则”字段把触发判断从“是否到期”改成“是否命中某个提醒节点”。一种轻量实现是给每条日程存一个RemindOffsets列表单位用分钟比如[4320, 1440, 60]分别代表提前 3 天、1 天、1 小时。定时器每次 Tick 时对每条未完成日程计算DueTime - now看这个剩余时间是否“跨过”了某个 offset 且该 offset 尚未触发。判断“跨过”要用区间比较而不是相等比较因为定时器有间隔剩余时间很难精确等于某个 offset。// 判断本次 Tick 是否命中了某个提醒节点 private bool HitOffset(ScheduleItem item, TimeSpan remaining) { foreach (var offset in item.RemindOffsets) { var target TimeSpan.FromMinutes(offset); // 剩余时间落在 [target - 刷新间隔, target] 区间内且该节点未触发 if (remaining target remaining target - TimeSpan.FromSeconds(2) !item.FiredOffsets.Contains(offset)) { item.FiredOffsets.Add(offset); return true; } } return false; }这里的TimeSpan.FromSeconds(2)是容差窗口要和定时器间隔匹配间隔 1 秒就设 2 秒容差间隔 5 秒就得放大到 6 秒以上否则可能整个窗口被跳过。FiredOffsets记录已触发的节点同样要持久化避免重启后重复提醒。这个设计的好处是策略完全数据驱动用户想加“提前 30 分钟”只需在列表里加个 30不用改代码。再进一步可以把提醒方式也做成按节点配置提前 3 天只发托盘气泡不响铃到期当天才响铃加弹窗。这需要在RemindOffsets旁边配一个方式枚举触发时按配置分发。复杂度上来了但对“不想被频繁打扰又怕漏事”的用户来说这个粒度才够用。验证策略是否生效我习惯用一个“时间加速”的调试开关在开发模式下把DateTime.Now替换成一个可手动推进的模拟时钟把剩余时间快速推到各个节点附近观察是否按预期触发。没有这个开关测一次“提前 3 天提醒”要真等三天根本不现实。这个习惯是从一次线上提醒全漏的教训里养成的——当时就是没做节点测试容差窗口设小了实际运行时定时器抖动直接跳过了窗口所有提前提醒全部失效。从那以后我每次改提醒逻辑都强制用模拟时钟把每个节点走一遍确认触发记录和实际提醒对得上才敢交付。希望这套拆解能帮到你把手里这个小工具改成真正盯得住事的那一个。本文还有配套的精品资源点击获取