每天要处理的琐事太多太碎系统闹钟、日历提醒和任务管理软件各有各的别扭。我直接用 C# 写了一款轻量定时工具把快捷时间选择、计划备注和状态批量管理塞进一个不到几百 KB 的单文件里平时就常驻系统托盘到点弹窗用了一年多非常顺手。这篇博文把整个工具从需求梳理、核心代码思路到实际踩坑的完整过程都拆开讲适合想用自己写的顺手工位提升效率的开发者也适合正在用 C# 做 WinForms 小工具的新手参考。1. 系统闹钟、日历和重型任务软件都差点意思逼我动手自研的核心原因1.1 碎片化提醒的日常困境我自己平时在职场里同时也是个生活琐事重灾区上午十点要提交周报下午两点半要跟进客户邮件傍晚六点要记得接孩子晚上九点还有个在线课程要签到。这些提醒之间没有任何逻辑关联但任何一个错过都挺麻烦。以前的解决方案无非这么几种Windows 系统闹钟到点响一声响完就没了。没有上下文响铃时经常想不起来我当初因为这个提醒是打算干什么。而且一次性设定第二天全部重来。日历软件Outlook 日历做日程没问题但你为一个35 分钟后跟同事对个 Qt 方案这种随机事件单独建一条日历邀请还是太隆重了。打开客户端、选时间、写事件、选提醒四步下来黄花菜都凉了。任务管理应用Notion、Trello、滴答清单这些确实强但对一个提醒场景来说都太重了。打开浏览器、登账号、加载云端数据再到新建任务启动成本远高于动作本身。我想做的事只是三秒内记一句话到点它提醒我不需要项目管理方法论。这就陷入了一个很尴尬的中间地带真正轻的没有备注和状态管理能做状态管理的不够轻。反复折腾了几轮之后我的结论是与其在各工具之间将就不如用 C# 自己写一个刚刚好的工具。1.2 产品定位轻才是第一需求这个工具从第一版开始就给自己划定了明确边界所有功能都围绕标题里那三个词快捷时间选择、计划备注、状态批量管理。具体就是单机桌面程序不联网不依赖云端。进程常驻系统托盘平时完全隐形到点才弹窗。主界面上 3 秒内能添加一条带备注的计划。所有计划集中在一个列表里可以勾选批量修改状态。这些功能如果放进大型任务管理软件里都有但组合方式完全不一样。下面是几个方案的对比我当初做选型的时候主要就是看几个关键维度维度系统自带闹钟日历/邮件客户端任务管理App自己写的轻量工具添加一条提醒耗时15秒以上流程繁琐30秒以上10-20秒看网络3-5秒是否支持备注不支持支持但格式重支持支持轻量输入状态管理无响完即弃有但绑定日程体系完备足够轻量的列表批量操作资源占用极低高偏高极低百MB级别内存内常驻不打扰无感常驻但不适配提醒通知栏通知多托盘图标到点才弹说白了市面上不缺功能强大的工具缺的是把添加成本压到极限的那种小工具。这个产品定位听起来很简单但实际设计功能时我会反复问自己一个问题这个功能会不会把添加一条计划的步骤从 3 秒变成 5 秒如果会就得重新设计交互。1.3 技术选型为什么选 C# 和 WinForms技术栈的选择没什么纠结的。这套工具的典型使用环境就是 Windows 桌面那我优先考虑的就是 C# WinForms。C#本身语法清晰泛型、LINQ、异步都很顺手做一个桌面小工具从开发效率到后期维护都很舒服。WinForms虽然经常被说老气但对于单窗口、列表、按钮交互这类需求它是天花板级的存在。控件齐、事件模型简单、资料多到搜不完。依赖少。我用 .NET 8 开发发布时选择单文件模式输出就一个 exe连 .NET 运行时都可以一起打包进去换台电脑拷过去直接双击就能跑。有人会问说现在不是很流行 WPF 或者 MVVM 吗我也想过但很快否掉了。原因很简单这个工具的核心是轻UI 复杂度远没有到需要 ViewModel、Command、BindableBase 那一套的程度引入 MVVM 框架反而会让代码膨胀。直接用 Code-Behind 处理事件文件小、逻辑直白、热启动速度快。这种尺度的工程去掉所有不必要的抽象就是最好的架构。2. 快捷时间选择的交互设计预设时间片和自定义时间的组合逻辑2.1 相对时间优先90% 的职场提醒是XX 分钟后这个工具最有成就感的功能其实是快捷时间选择。一开始我还想当然地照常规闹钟去做给用户一个DateTimePicker控件让他选几点几分。但真正用起来之后发现我的使用习惯根本不是这样。大多数时候我需要的提醒是35 分钟后要去开会、20 分钟后抢个秒杀、1 小时后把代码提交了——是相对时间不是绝对时间。绝对时间需要我打开日历看现在几点、还要心算一个差值这是一个明显的认知负担。所以我最后的方案是两套入口并行入口适用场景交互方式预设时间片按钮短倒计时型提醒点击30分钟直接添加DateTimePicker明确的绝对时间型提醒选择具体日期和时间后添加具体来说主界面顶部就是一行输入框 一排按钮。输入框中写好计划的标题比如给客户回邮件然后可以直接点右侧的15分钟30分钟1小时2小时半天一天这几个预设按钮点了就直接创建一条倒计时计划。如果你要的是固定时间比如明天上午 9 点那就在旁边的DateTimePicker里选好具体时间再点添加。这个交互设计我试过很多次最后确认了核心原则方案一人不动时间动。用户输入完标题手都不用离开键盘上方伸一根手指点一下时间按钮就够了。整个添加操作耗时不超过两秒这在日常使用中极其重要——你正在忙的时候两秒钟挤出来很容易超过五秒的操作很多时候就随手用白纸记了。2.2 WinForms Timer 轮询一个全局 Timer 比每条计划一个 Timer 靠谱再来看技术实现。这个功能里最容易出问题的其实是定时机制。做定时提醒脑子里第一反应可能是每条计划创建一个 Timer 实例。这个方案只适合计划极少的情况一旦计划多了你会遇到两个问题每个 Timer 都是独立对象生命周期你得小心翼翼地管理删除计划时忘了 Dispose内存和句柄都会缓慢泄漏。多条 Timer 醒来的时间点不一致批量改状态、暂停、通知弹窗的逻辑会变得无比混乱。我的做法是全局只维护一个System.Windows.Forms.Timer每秒钟 Tick 一次每次扫描整个计划列表把到点的计划筛选出来统一处理。var timer new System.Windows.Forms.Timer(); timer.Interval 1000; timer.Tick (s, e) { var now DateTime.Now; var duePlans _plans .Where(p p.Status PlanStatus.Pending p.DueTime now) .ToList(); foreach (var plan in duePlans) { plan.Status PlanStatus.Running; // 先标记为已触发 ShowReminderForm(plan); // 在 UI 线程中弹出提醒 } RefreshListControl(); // 刷新列表视图 }; timer.Start();注意这里我用的是System.Windows.Forms.Timer而不是System.Threading.Timer。这两个名字特别像实际行为差别很大System.Windows.Forms.Timer的 Tick 事件回调运行在 UI 线程上。这意味着事件里你可以直接操作 TextBox、ListView 等控件不需要Invoke。System.Threading.Timer是线程池里的定时器回调线程完全不是 UI 线程直接在回调里更新控件会抛InvalidOperationException跨线程操作异常。这个坑在 C# 论坛和热搜里极其常见几乎每个写 WinForms 的人都被它坑过。有人可能会担心每秒扫描一次会不会浪费。我实际测过一个普通列表遍历几千条记录的开销是微秒到几十微秒级别不到一毫秒的 CPU 时间比起数据库 IO、网络请求根本不值一提。全局轮询是这把场景里的最优解不采购额外内存也不用处理复杂的定时器生命周期。2.3 计划备注为什么越短越有用标题里提到的计划备注也是经过反复思考才定下来的。一开始我甚至觉得备注是多余的提醒弹窗显示标题不就够了结果用了几次之后发现不够。比如我设置了一条标题为项目管理会的提醒到点弹窗时我盯着它愣了几秒脑子里全是问号这个会在哪个会议室我需不需要提前打印材料是线上还是线下这些上下文信息完全没被带走提醒就只是个铃声没有任何行动指导价值。于是第二版加入了备注字段添加计划时输入框标题下方可以填一行备注支持多行但我个人建议限制在 50 字以内。备注的作用不是写长篇大论而是记录回答到点后我要干什么这个问题的关键信息会议室是3F-02备注写3F-02提前 5 分钟到客户邮件要回的要点备注写回复报价附 8 月合同扫描件接孩子的路上要买的东西备注写放学门口接顺路买牛奶和吐司因为方案里的所有信息都在一个列表里备注必须能在一扫之间读完超过两行的备注我会改成描述更精简的句子。这个约束反而逼着我在输入时整理思路把真正重要的话留下来。3. 状态批量管理计划从待处理到完成的一条清晰流转路径3.1 状态机设计四种状态足够覆盖全局不要多余的复杂度计划加进来之后不能被一个个丢在列表里状态管理必须跟上。我给每条计划设计了四种状态刻意没有引入第五种Pending待提醒等待时间到达。Running已触发人可能正在处理这件事但还没标记完成。Completed已完成。Cancelled已取消根本不打算执行。这四种状态本质上对应了计划生命周期的四个节点未到时间 — 已到时间但还没做完 — 做完 — 放弃。有人会建议加Overdue 逾期Postponed 推迟Doing 进行中之类我测试过加了之后反而让列表变得难以扫读状态种类越多用户做判断时需要阅读的信息越多。实际实现上一个含 Id 的后端实体类加一个前端显示映射就够了public enum PlanStatus { Pending 0, Running 1, Completed 2, Cancelled 3 } public class PlanItem { public int Id { get; set; } public string Title { get; set; } public string Note { get; set; } public DateTime DueTime { get; set; } public PlanStatus Status { get; set; } }前端展示用一个ListView在大图标模式下每条计划显示成一排根据 Status 映射前景色和背景色。Pending 是黑色Running 是深蓝色Completed 是灰色并显示完成时间Cancelled 是浅灰色再加删除线。整个映射表写在一个静态方法里刷新列表时直接查表不需要到处散落颜色常量。3.2 批量操作是省时间的灵魂多选、右键菜单与快捷键状态管理的价值在批量这两个字上体现得淋漓尽致。如果一次只改一条计划状态那用普通 Todo 应用也没差。但真实职场场景里状态变更往往是批量发生的早上进办公室先看列表里所有待提醒的计划把昨天遗留的几条 Running 计划全部标记 Completed。下午例会前把今天务必要完成的三条计划选中统一标记为 Running表示我现在开始集中攻这几件。临下班把拖了一天已经没意义了的几条计划一起取消。操作设计是ListView支持多选。按住 Ctrl 或 Shift 点击可以选多条CtrlA 全选。选中之后右键菜单里提供以下操作菜单项行为是否弹确认标记为已完成批量修改状态记录完成时间否标记为进行中批量修改状态否标记为已取消批量修改状态否复制为新计划把选中项拷贝成新的 Pending 计划否删除计划从文件中永久移除是弹确认框快键和右键菜单配合使用非常顺手F2 编辑、Delete 删除、空格切换选中回车触发标记为已完成。实测下来每天晚上复盘时把当天二十几条计划清一遍全程不超过十秒。这里有一个特别值得说的设计决策批量修改状态不要弹确认框但批量删除必须弹确认框。状态改错了随时可以改回来柯南式误操作成本很低删除不可恢复数据丢了就是丢了。所以我把确认逻辑和可逆性绑在一起越容易逆的操作越不需要确认。3.3 轻量持久化JSON 文件方案不碰数据库计划数据需要保存程序退出后再启动时恢复。这个需求我用一个 JSON 文件解决不引入 SQLite 或任何数据库。文件放在可执行目录下的plans.json结构就是一个ListPlanItem的序列化结果。用System.Text.Json读写代码量非常少public void SavePlans(string path) { var json JsonSerializer.Serialize(_plans, new JsonSerializerOptions { WriteIndented true }); // 先写临时文件再替换正式文件避免断电导致 JSON 损坏 var tempPath path .tmp; File.WriteAllText(tempPath, json, Encoding.UTF8); File.Delete(path); // 注释准备调整 File.Move(tempPath, path); } public void LoadPlans(string path) { if (!File.Exists(path)) return; var json File.ReadAllText(path, Encoding.UTF8); _plans JsonSerializer.DeserializeListPlanItem(json) ?? new ListPlanItem(); }写文件的时候特意做了先写临时文件再覆盖的处理。别小看这一步我有一次程序运行时突然断电重启后发现plans.json里全是乱码几十条计划全丢了。后来的临时文件方案虽然不能完全防住断电但损坏概率大幅降低至少在正常退出和大多数异常退出场景下是安全的。不需要数据库的理由也很实际这个工具的数据量是条级别几百条计划撑死也就几十 KB一个 JSON 文件可读、可改、可备份遇到数据问题打开文件直接就能诊断。SQLite 在这个尺度下只会引入依赖和管理成本。3.4 列表排序未处理的永远在最上面干净的完成区沉底状态管理离不开列表排序排序逻辑我用了一个简单但极其有效的规则未处理Pending Running计划按DueTime升序排在最上面最近要到点的排第一醒目。已完成Completed计划沉底按完成时间倒序最近刚完成的排在完成区最上面方便回溯。已取消Cancelled计划默认折叠在一个分组里不在主视图中占位。这个排序带来的体验变化是革命性的。之前的版本里所有计划混在一起每天早上一打开列表乌泱泱一片让人下意识想逃避。现在打开第一眼看到的就是现在要我处理什么完成区安静地躺在下面成就感来自看着它的高度一天天增长。4. 踩过的真实坑Timer 线程、最小化托盘和删数据的误操作4.1 Timer 访问控件从偶发闪退到理解 UI 线程这个坑值得一提因为几乎每个 C# WinForms 开发者都会踩到我当年在另一个项目里也摔过。早期版本里我曾经用过System.Threading.Timer做每秒扫描。这玩意儿的回调默认跑在线程池线程上所以当我在回调里直接写listView.Items.Clear()或者statusLabel.Text ...时程序运行到某个瞬间就突然闪退了。控制台里打印的异常信息永远都是线程间操作无效从不是创建控件listView的线程访问它。这个问题在热搜词里出现频率极高c# timer 访问控件c# winform 如何更新状态栏与进度条搜出来的结果绕不开 Invoke。当时的正确解决方法是包一层BeginInvokeprivate void UiSafeAction(Action action) { if (listView.InvokeRequired) listView.BeginInvoke(action); else action(); }这样写本身是没问题的但我在这个轻量工具里更推荐前文说到的方法直接改用System.Windows.Forms.Timer让所有逻辑都天然跑在 UI 线程上源码里少了一个分支脑子里的线程模型也简单一截。轻量工具不该把复杂度揽到自己身上能用简单 API 解决就不引入多线程。4.2 最小化到托盘后提醒窗口怎么弹才不隐身程序要常驻必然要做最小化到托盘关闭主窗口不要退出程序而是缩小为托盘图标。这一步实现了之后又冒出来一个新问题窗口最小化到托盘后到点弹出提醒窗口用户那边往往根本看不见。为什么看不见因为当主窗体是隐藏状态时弹出的提醒窗体如果不特意设置TopMost它只会作为普通窗口出现在任务栏上。如果用户当时正全屏看文档、开会投屏、或者人根本不在电脑前比如去接水了那就和没提醒一样。我的解决方式是组合拳NotifyIcon托盘图标常驻气泡显示提醒摘要标题 备注前两行。真正的提醒窗体设置为TopMost true和ShowInTaskbar true保证它压在所有窗口最上面弹出来。提醒窗体默认带一个高亮的红色标题栏视觉上强提醒关闭按钮旁边加一个稍后提醒5 分钟按钮可以把同一计划延迟五分钟再弹。试了几周之后我甚至发现一个反直觉的事情稍微让提醒窗体丑一点、大一点、明显一点反而更受欢迎。因为它的职责就是打断你不需要优雅需要你没法忽略。4.3 数据删除的误操作保护CtrlZ 撤销删除有一次我在列表上批量把已完成状态的计划全选删掉手一抖把第二天的几条 Pending 计划也一起选中删了。当时那个版本删除前没有确认框数据直接从 JSON 文件里抹掉了我再找回时已经晚了。那之后我做了三层防护现在基本不会再误删重要计划层级防护策略说明第一层删除前弹确认框显示数量按确定才会真正执行第二层删除项进入内存回收站保留最近删除的 20 条供 CtrlZ 撤销第三层列表底部增加查看回收站按钮手动恢复错删的计划删除时记录操作日志实现上删除执行前把所有PlanItem快照放到一个StackListPlanItem里CtrlZ 时从栈顶弹出一个快照直接恢复整个列表。这个方案简单粗暴但对单机小工具非常可靠。撤销删除的体验和写 Word 一样按一下键盘就安心了。还有一个容易被忽略的小坑删除前注意检查计划里是否有DueTime已经过去但状态还是 Pending 的僵尸计划。这种计划建议在删除确认框里用红色提示包含 X 条已过期未处理计划避免用户糊里糊涂地删掉还没处理的重要事项。5. 从能用到好用提醒弹窗细节、自启动和其他扩展方向5.1 提醒窗口的细节字号、按钮、声音缺一不可提醒窗口的设计其实一开始只是想着能弹出来就行。但真正用起来细节决定成败。字号大提醒窗口标题至少 18 号以上为了目标是在 3 米外扫一眼也能看清是什么事。时间明确窗口内显示现在和原定提醒时间两个时间。特别是你不在电脑前回来时看到原定 14:30 提醒现在 15:10立刻能判断已经晚了多久。备注完整显示提醒窗口不用文本框用Label自动换行。避免用户还得点开详情才能看到备注。声音友好我不用系统默认的叮而是通过SoundPlayer播放SystemSounds.Exclamation同时在不打扰的前提下不循环播放。另一个很实用的补充是稍后提醒的间隔选择。提醒窗里提供5 分钟10 分钟30 分钟三个按钮点击后计划状态会从 Running 回退为 Pending再把DueTime延后对应分钟数。这比重新创建一条计划要自然得多。5.2 自启动 启动即最小化 简单日志既然定位是常驻工具那开机自启是刚需。实现方式就是在注册表的HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run下加一个指向 exe 的键值。这样只影响当前用户不需要管理员权限卸载时删掉键值即可。自启动之后程序需要支持启动参数-minimized否则每次开机都会弹出一个完整主窗口很烦人。我在Main函数里做参数判断带了这个参数就只初始化托盘、不显示主窗体。日志功能我一开始觉得没必要但后来坚持加了一行。每次状态变更时向log.txt追加一行记录比如2025-01-07 15:00:12 | 计划#23 到点提醒客户邮件跟进 2025-01-07 15:01:44 | 计划#23 标记完成在月复盘时用 Excel 导入这个 log 文件直观看到自己每天完成了多少条计划、平均延迟多久、哪类计划总是被取消。这个日志不是给程序看的是给自己看的。工具提供了数据人才能真正意识到自己把时间花在了哪里。5.3 我这一个多月的实际使用数据与体感这个工具从开发完成到现在我每天都用它一个多月下来统计了一些数字平均每天添加计划 9-13 条绝大多数都是30 分钟和1 小时这两个快捷按钮添加的。添加一条计划的平均用时大约 3 秒标题 点按钮比之前用 Outlook 日历至少快了 5 倍。当天完成率从以前的 40% 左右提升到 85% 以上。原因不是我的自制力变强了而是因为所有低成本的提醒都被集中摆在了眼前少了忘了这回事的情况。这条工具最值钱的其实是我可以完全忘掉它添加计划时不用惦记着设闹钟、不用安排分类、不用考虑优先级删掉那些过程步骤计划本身的执行反而更顺畅。有人说提醒工具会让人过度依赖我反倒觉得这是好事。人的大脑不该用来记这些碎片时间点把记忆外包给工具节省出来的注意力去处理真正需要思考的工作这才是用钱的常识。5.4 后续扩展的想法从托盘工具到个人时间数据源最后也想聊聊后续可扩展的方向倒不是说要加多少功能而是给有类似想法的人提供一个思路参考计划备注里直接支持环境变量和外部程序调用。比如备注写成%COMSPEC% /c start daily-report.md到点弹出提醒时可以直接打开对应文档甚至执行一个外部命令。导出 CSV 做周复盘。目前 log 里的数据是纯文本扩展一步就是做成结构化 CSV更快地和表格软件打通。Webhook 通知。如果希望手机也收到提醒可以后续在程序里加一个 HTTP 请求到个人服务器的接口到点后转发一条通知。这属于可选功能不做也不影响本机体验。多套提醒方案。比如节假日跳过、滚动提醒这些在现在基础上做起来都不复杂但我不打算全塞进来——轻量工具的底线是永远别往里面塞超过需求的功能。做这个小工具收获最大的不是我写了多少行代码而是我逐渐理解了工具给人带来幸福感到底是什么意思把最常用的操作做到 3 秒级别把状态管理压缩到一个列表一次右键然后把所有需要记忆的部分交给文件整个人反而获得了更多可支配的注意力。这些设计决策其实都围绕同一个核心——降低启动成本。文章里所有坑和优化也都来自这个原则如果你也想做个类似的个人小工具建议别急着加功能先把自己最常用的那个动作做到极致的简单剩下的自然会慢慢长出来。
每天要处理的琐事太多太碎系统闹钟、日历提醒和任务管理软件各有各的别扭。我直接用 C# 写了一款轻量定时工具把快捷时间选择、计划备注和状态批量管理塞进一个不到几百 KB 的单文件里平时就常驻系统托盘到点弹窗用了一年多非常顺手。这篇博文把整个工具从需求梳理、核心代码思路到实际踩坑的完整过程都拆开讲适合想用自己写的顺手工位提升效率的开发者也适合正在用 C# 做 WinForms 小工具的新手参考。1. 系统闹钟、日历和重型任务软件都差点意思逼我动手自研的核心原因1.1 碎片化提醒的日常困境我自己平时在职场里同时也是个生活琐事重灾区上午十点要提交周报下午两点半要跟进客户邮件傍晚六点要记得接孩子晚上九点还有个在线课程要签到。这些提醒之间没有任何逻辑关联但任何一个错过都挺麻烦。以前的解决方案无非这么几种Windows 系统闹钟到点响一声响完就没了。没有上下文响铃时经常想不起来我当初因为这个提醒是打算干什么。而且一次性设定第二天全部重来。日历软件Outlook 日历做日程没问题但你为一个35 分钟后跟同事对个 Qt 方案这种随机事件单独建一条日历邀请还是太隆重了。打开客户端、选时间、写事件、选提醒四步下来黄花菜都凉了。任务管理应用Notion、Trello、滴答清单这些确实强但对一个提醒场景来说都太重了。打开浏览器、登账号、加载云端数据再到新建任务启动成本远高于动作本身。我想做的事只是三秒内记一句话到点它提醒我不需要项目管理方法论。这就陷入了一个很尴尬的中间地带真正轻的没有备注和状态管理能做状态管理的不够轻。反复折腾了几轮之后我的结论是与其在各工具之间将就不如用 C# 自己写一个刚刚好的工具。1.2 产品定位轻才是第一需求这个工具从第一版开始就给自己划定了明确边界所有功能都围绕标题里那三个词快捷时间选择、计划备注、状态批量管理。具体就是单机桌面程序不联网不依赖云端。进程常驻系统托盘平时完全隐形到点才弹窗。主界面上 3 秒内能添加一条带备注的计划。所有计划集中在一个列表里可以勾选批量修改状态。这些功能如果放进大型任务管理软件里都有但组合方式完全不一样。下面是几个方案的对比我当初做选型的时候主要就是看几个关键维度维度系统自带闹钟日历/邮件客户端任务管理App自己写的轻量工具添加一条提醒耗时15秒以上流程繁琐30秒以上10-20秒看网络3-5秒是否支持备注不支持支持但格式重支持支持轻量输入状态管理无响完即弃有但绑定日程体系完备足够轻量的列表批量操作资源占用极低高偏高极低百MB级别内存内常驻不打扰无感常驻但不适配提醒通知栏通知多托盘图标到点才弹说白了市面上不缺功能强大的工具缺的是把添加成本压到极限的那种小工具。这个产品定位听起来很简单但实际设计功能时我会反复问自己一个问题这个功能会不会把添加一条计划的步骤从 3 秒变成 5 秒如果会就得重新设计交互。1.3 技术选型为什么选 C# 和 WinForms技术栈的选择没什么纠结的。这套工具的典型使用环境就是 Windows 桌面那我优先考虑的就是 C# WinForms。C#本身语法清晰泛型、LINQ、异步都很顺手做一个桌面小工具从开发效率到后期维护都很舒服。WinForms虽然经常被说老气但对于单窗口、列表、按钮交互这类需求它是天花板级的存在。控件齐、事件模型简单、资料多到搜不完。依赖少。我用 .NET 8 开发发布时选择单文件模式输出就一个 exe连 .NET 运行时都可以一起打包进去换台电脑拷过去直接双击就能跑。有人会问说现在不是很流行 WPF 或者 MVVM 吗我也想过但很快否掉了。原因很简单这个工具的核心是轻UI 复杂度远没有到需要 ViewModel、Command、BindableBase 那一套的程度引入 MVVM 框架反而会让代码膨胀。直接用 Code-Behind 处理事件文件小、逻辑直白、热启动速度快。这种尺度的工程去掉所有不必要的抽象就是最好的架构。2. 快捷时间选择的交互设计预设时间片和自定义时间的组合逻辑2.1 相对时间优先90% 的职场提醒是XX 分钟后这个工具最有成就感的功能其实是快捷时间选择。一开始我还想当然地照常规闹钟去做给用户一个DateTimePicker控件让他选几点几分。但真正用起来之后发现我的使用习惯根本不是这样。大多数时候我需要的提醒是35 分钟后要去开会、20 分钟后抢个秒杀、1 小时后把代码提交了——是相对时间不是绝对时间。绝对时间需要我打开日历看现在几点、还要心算一个差值这是一个明显的认知负担。所以我最后的方案是两套入口并行入口适用场景交互方式预设时间片按钮短倒计时型提醒点击30分钟直接添加DateTimePicker明确的绝对时间型提醒选择具体日期和时间后添加具体来说主界面顶部就是一行输入框 一排按钮。输入框中写好计划的标题比如给客户回邮件然后可以直接点右侧的15分钟30分钟1小时2小时半天一天这几个预设按钮点了就直接创建一条倒计时计划。如果你要的是固定时间比如明天上午 9 点那就在旁边的DateTimePicker里选好具体时间再点添加。这个交互设计我试过很多次最后确认了核心原则方案一人不动时间动。用户输入完标题手都不用离开键盘上方伸一根手指点一下时间按钮就够了。整个添加操作耗时不超过两秒这在日常使用中极其重要——你正在忙的时候两秒钟挤出来很容易超过五秒的操作很多时候就随手用白纸记了。2.2 WinForms Timer 轮询一个全局 Timer 比每条计划一个 Timer 靠谱再来看技术实现。这个功能里最容易出问题的其实是定时机制。做定时提醒脑子里第一反应可能是每条计划创建一个 Timer 实例。这个方案只适合计划极少的情况一旦计划多了你会遇到两个问题每个 Timer 都是独立对象生命周期你得小心翼翼地管理删除计划时忘了 Dispose内存和句柄都会缓慢泄漏。多条 Timer 醒来的时间点不一致批量改状态、暂停、通知弹窗的逻辑会变得无比混乱。我的做法是全局只维护一个System.Windows.Forms.Timer每秒钟 Tick 一次每次扫描整个计划列表把到点的计划筛选出来统一处理。var timer new System.Windows.Forms.Timer(); timer.Interval 1000; timer.Tick (s, e) { var now DateTime.Now; var duePlans _plans .Where(p p.Status PlanStatus.Pending p.DueTime now) .ToList(); foreach (var plan in duePlans) { plan.Status PlanStatus.Running; // 先标记为已触发 ShowReminderForm(plan); // 在 UI 线程中弹出提醒 } RefreshListControl(); // 刷新列表视图 }; timer.Start();注意这里我用的是System.Windows.Forms.Timer而不是System.Threading.Timer。这两个名字特别像实际行为差别很大System.Windows.Forms.Timer的 Tick 事件回调运行在 UI 线程上。这意味着事件里你可以直接操作 TextBox、ListView 等控件不需要Invoke。System.Threading.Timer是线程池里的定时器回调线程完全不是 UI 线程直接在回调里更新控件会抛InvalidOperationException跨线程操作异常。这个坑在 C# 论坛和热搜里极其常见几乎每个写 WinForms 的人都被它坑过。有人可能会担心每秒扫描一次会不会浪费。我实际测过一个普通列表遍历几千条记录的开销是微秒到几十微秒级别不到一毫秒的 CPU 时间比起数据库 IO、网络请求根本不值一提。全局轮询是这把场景里的最优解不采购额外内存也不用处理复杂的定时器生命周期。2.3 计划备注为什么越短越有用标题里提到的计划备注也是经过反复思考才定下来的。一开始我甚至觉得备注是多余的提醒弹窗显示标题不就够了结果用了几次之后发现不够。比如我设置了一条标题为项目管理会的提醒到点弹窗时我盯着它愣了几秒脑子里全是问号这个会在哪个会议室我需不需要提前打印材料是线上还是线下这些上下文信息完全没被带走提醒就只是个铃声没有任何行动指导价值。于是第二版加入了备注字段添加计划时输入框标题下方可以填一行备注支持多行但我个人建议限制在 50 字以内。备注的作用不是写长篇大论而是记录回答到点后我要干什么这个问题的关键信息会议室是3F-02备注写3F-02提前 5 分钟到客户邮件要回的要点备注写回复报价附 8 月合同扫描件接孩子的路上要买的东西备注写放学门口接顺路买牛奶和吐司因为方案里的所有信息都在一个列表里备注必须能在一扫之间读完超过两行的备注我会改成描述更精简的句子。这个约束反而逼着我在输入时整理思路把真正重要的话留下来。3. 状态批量管理计划从待处理到完成的一条清晰流转路径3.1 状态机设计四种状态足够覆盖全局不要多余的复杂度计划加进来之后不能被一个个丢在列表里状态管理必须跟上。我给每条计划设计了四种状态刻意没有引入第五种Pending待提醒等待时间到达。Running已触发人可能正在处理这件事但还没标记完成。Completed已完成。Cancelled已取消根本不打算执行。这四种状态本质上对应了计划生命周期的四个节点未到时间 — 已到时间但还没做完 — 做完 — 放弃。有人会建议加Overdue 逾期Postponed 推迟Doing 进行中之类我测试过加了之后反而让列表变得难以扫读状态种类越多用户做判断时需要阅读的信息越多。实际实现上一个含 Id 的后端实体类加一个前端显示映射就够了public enum PlanStatus { Pending 0, Running 1, Completed 2, Cancelled 3 } public class PlanItem { public int Id { get; set; } public string Title { get; set; } public string Note { get; set; } public DateTime DueTime { get; set; } public PlanStatus Status { get; set; } }前端展示用一个ListView在大图标模式下每条计划显示成一排根据 Status 映射前景色和背景色。Pending 是黑色Running 是深蓝色Completed 是灰色并显示完成时间Cancelled 是浅灰色再加删除线。整个映射表写在一个静态方法里刷新列表时直接查表不需要到处散落颜色常量。3.2 批量操作是省时间的灵魂多选、右键菜单与快捷键状态管理的价值在批量这两个字上体现得淋漓尽致。如果一次只改一条计划状态那用普通 Todo 应用也没差。但真实职场场景里状态变更往往是批量发生的早上进办公室先看列表里所有待提醒的计划把昨天遗留的几条 Running 计划全部标记 Completed。下午例会前把今天务必要完成的三条计划选中统一标记为 Running表示我现在开始集中攻这几件。临下班把拖了一天已经没意义了的几条计划一起取消。操作设计是ListView支持多选。按住 Ctrl 或 Shift 点击可以选多条CtrlA 全选。选中之后右键菜单里提供以下操作菜单项行为是否弹确认标记为已完成批量修改状态记录完成时间否标记为进行中批量修改状态否标记为已取消批量修改状态否复制为新计划把选中项拷贝成新的 Pending 计划否删除计划从文件中永久移除是弹确认框快键和右键菜单配合使用非常顺手F2 编辑、Delete 删除、空格切换选中回车触发标记为已完成。实测下来每天晚上复盘时把当天二十几条计划清一遍全程不超过十秒。这里有一个特别值得说的设计决策批量修改状态不要弹确认框但批量删除必须弹确认框。状态改错了随时可以改回来柯南式误操作成本很低删除不可恢复数据丢了就是丢了。所以我把确认逻辑和可逆性绑在一起越容易逆的操作越不需要确认。3.3 轻量持久化JSON 文件方案不碰数据库计划数据需要保存程序退出后再启动时恢复。这个需求我用一个 JSON 文件解决不引入 SQLite 或任何数据库。文件放在可执行目录下的plans.json结构就是一个ListPlanItem的序列化结果。用System.Text.Json读写代码量非常少public void SavePlans(string path) { var json JsonSerializer.Serialize(_plans, new JsonSerializerOptions { WriteIndented true }); // 先写临时文件再替换正式文件避免断电导致 JSON 损坏 var tempPath path .tmp; File.WriteAllText(tempPath, json, Encoding.UTF8); File.Delete(path); // 注释准备调整 File.Move(tempPath, path); } public void LoadPlans(string path) { if (!File.Exists(path)) return; var json File.ReadAllText(path, Encoding.UTF8); _plans JsonSerializer.DeserializeListPlanItem(json) ?? new ListPlanItem(); }写文件的时候特意做了先写临时文件再覆盖的处理。别小看这一步我有一次程序运行时突然断电重启后发现plans.json里全是乱码几十条计划全丢了。后来的临时文件方案虽然不能完全防住断电但损坏概率大幅降低至少在正常退出和大多数异常退出场景下是安全的。不需要数据库的理由也很实际这个工具的数据量是条级别几百条计划撑死也就几十 KB一个 JSON 文件可读、可改、可备份遇到数据问题打开文件直接就能诊断。SQLite 在这个尺度下只会引入依赖和管理成本。3.4 列表排序未处理的永远在最上面干净的完成区沉底状态管理离不开列表排序排序逻辑我用了一个简单但极其有效的规则未处理Pending Running计划按DueTime升序排在最上面最近要到点的排第一醒目。已完成Completed计划沉底按完成时间倒序最近刚完成的排在完成区最上面方便回溯。已取消Cancelled计划默认折叠在一个分组里不在主视图中占位。这个排序带来的体验变化是革命性的。之前的版本里所有计划混在一起每天早上一打开列表乌泱泱一片让人下意识想逃避。现在打开第一眼看到的就是现在要我处理什么完成区安静地躺在下面成就感来自看着它的高度一天天增长。4. 踩过的真实坑Timer 线程、最小化托盘和删数据的误操作4.1 Timer 访问控件从偶发闪退到理解 UI 线程这个坑值得一提因为几乎每个 C# WinForms 开发者都会踩到我当年在另一个项目里也摔过。早期版本里我曾经用过System.Threading.Timer做每秒扫描。这玩意儿的回调默认跑在线程池线程上所以当我在回调里直接写listView.Items.Clear()或者statusLabel.Text ...时程序运行到某个瞬间就突然闪退了。控制台里打印的异常信息永远都是线程间操作无效从不是创建控件listView的线程访问它。这个问题在热搜词里出现频率极高c# timer 访问控件c# winform 如何更新状态栏与进度条搜出来的结果绕不开 Invoke。当时的正确解决方法是包一层BeginInvokeprivate void UiSafeAction(Action action) { if (listView.InvokeRequired) listView.BeginInvoke(action); else action(); }这样写本身是没问题的但我在这个轻量工具里更推荐前文说到的方法直接改用System.Windows.Forms.Timer让所有逻辑都天然跑在 UI 线程上源码里少了一个分支脑子里的线程模型也简单一截。轻量工具不该把复杂度揽到自己身上能用简单 API 解决就不引入多线程。4.2 最小化到托盘后提醒窗口怎么弹才不隐身程序要常驻必然要做最小化到托盘关闭主窗口不要退出程序而是缩小为托盘图标。这一步实现了之后又冒出来一个新问题窗口最小化到托盘后到点弹出提醒窗口用户那边往往根本看不见。为什么看不见因为当主窗体是隐藏状态时弹出的提醒窗体如果不特意设置TopMost它只会作为普通窗口出现在任务栏上。如果用户当时正全屏看文档、开会投屏、或者人根本不在电脑前比如去接水了那就和没提醒一样。我的解决方式是组合拳NotifyIcon托盘图标常驻气泡显示提醒摘要标题 备注前两行。真正的提醒窗体设置为TopMost true和ShowInTaskbar true保证它压在所有窗口最上面弹出来。提醒窗体默认带一个高亮的红色标题栏视觉上强提醒关闭按钮旁边加一个稍后提醒5 分钟按钮可以把同一计划延迟五分钟再弹。试了几周之后我甚至发现一个反直觉的事情稍微让提醒窗体丑一点、大一点、明显一点反而更受欢迎。因为它的职责就是打断你不需要优雅需要你没法忽略。4.3 数据删除的误操作保护CtrlZ 撤销删除有一次我在列表上批量把已完成状态的计划全选删掉手一抖把第二天的几条 Pending 计划也一起选中删了。当时那个版本删除前没有确认框数据直接从 JSON 文件里抹掉了我再找回时已经晚了。那之后我做了三层防护现在基本不会再误删重要计划层级防护策略说明第一层删除前弹确认框显示数量按确定才会真正执行第二层删除项进入内存回收站保留最近删除的 20 条供 CtrlZ 撤销第三层列表底部增加查看回收站按钮手动恢复错删的计划删除时记录操作日志实现上删除执行前把所有PlanItem快照放到一个StackListPlanItem里CtrlZ 时从栈顶弹出一个快照直接恢复整个列表。这个方案简单粗暴但对单机小工具非常可靠。撤销删除的体验和写 Word 一样按一下键盘就安心了。还有一个容易被忽略的小坑删除前注意检查计划里是否有DueTime已经过去但状态还是 Pending 的僵尸计划。这种计划建议在删除确认框里用红色提示包含 X 条已过期未处理计划避免用户糊里糊涂地删掉还没处理的重要事项。5. 从能用到好用提醒弹窗细节、自启动和其他扩展方向5.1 提醒窗口的细节字号、按钮、声音缺一不可提醒窗口的设计其实一开始只是想着能弹出来就行。但真正用起来细节决定成败。字号大提醒窗口标题至少 18 号以上为了目标是在 3 米外扫一眼也能看清是什么事。时间明确窗口内显示现在和原定提醒时间两个时间。特别是你不在电脑前回来时看到原定 14:30 提醒现在 15:10立刻能判断已经晚了多久。备注完整显示提醒窗口不用文本框用Label自动换行。避免用户还得点开详情才能看到备注。声音友好我不用系统默认的叮而是通过SoundPlayer播放SystemSounds.Exclamation同时在不打扰的前提下不循环播放。另一个很实用的补充是稍后提醒的间隔选择。提醒窗里提供5 分钟10 分钟30 分钟三个按钮点击后计划状态会从 Running 回退为 Pending再把DueTime延后对应分钟数。这比重新创建一条计划要自然得多。5.2 自启动 启动即最小化 简单日志既然定位是常驻工具那开机自启是刚需。实现方式就是在注册表的HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run下加一个指向 exe 的键值。这样只影响当前用户不需要管理员权限卸载时删掉键值即可。自启动之后程序需要支持启动参数-minimized否则每次开机都会弹出一个完整主窗口很烦人。我在Main函数里做参数判断带了这个参数就只初始化托盘、不显示主窗体。日志功能我一开始觉得没必要但后来坚持加了一行。每次状态变更时向log.txt追加一行记录比如2025-01-07 15:00:12 | 计划#23 到点提醒客户邮件跟进 2025-01-07 15:01:44 | 计划#23 标记完成在月复盘时用 Excel 导入这个 log 文件直观看到自己每天完成了多少条计划、平均延迟多久、哪类计划总是被取消。这个日志不是给程序看的是给自己看的。工具提供了数据人才能真正意识到自己把时间花在了哪里。5.3 我这一个多月的实际使用数据与体感这个工具从开发完成到现在我每天都用它一个多月下来统计了一些数字平均每天添加计划 9-13 条绝大多数都是30 分钟和1 小时这两个快捷按钮添加的。添加一条计划的平均用时大约 3 秒标题 点按钮比之前用 Outlook 日历至少快了 5 倍。当天完成率从以前的 40% 左右提升到 85% 以上。原因不是我的自制力变强了而是因为所有低成本的提醒都被集中摆在了眼前少了忘了这回事的情况。这条工具最值钱的其实是我可以完全忘掉它添加计划时不用惦记着设闹钟、不用安排分类、不用考虑优先级删掉那些过程步骤计划本身的执行反而更顺畅。有人说提醒工具会让人过度依赖我反倒觉得这是好事。人的大脑不该用来记这些碎片时间点把记忆外包给工具节省出来的注意力去处理真正需要思考的工作这才是用钱的常识。5.4 后续扩展的想法从托盘工具到个人时间数据源最后也想聊聊后续可扩展的方向倒不是说要加多少功能而是给有类似想法的人提供一个思路参考计划备注里直接支持环境变量和外部程序调用。比如备注写成%COMSPEC% /c start daily-report.md到点弹出提醒时可以直接打开对应文档甚至执行一个外部命令。导出 CSV 做周复盘。目前 log 里的数据是纯文本扩展一步就是做成结构化 CSV更快地和表格软件打通。Webhook 通知。如果希望手机也收到提醒可以后续在程序里加一个 HTTP 请求到个人服务器的接口到点后转发一条通知。这属于可选功能不做也不影响本机体验。多套提醒方案。比如节假日跳过、滚动提醒这些在现在基础上做起来都不复杂但我不打算全塞进来——轻量工具的底线是永远别往里面塞超过需求的功能。做这个小工具收获最大的不是我写了多少行代码而是我逐渐理解了工具给人带来幸福感到底是什么意思把最常用的操作做到 3 秒级别把状态管理压缩到一个列表一次右键然后把所有需要记忆的部分交给文件整个人反而获得了更多可支配的注意力。这些设计决策其实都围绕同一个核心——降低启动成本。文章里所有坑和优化也都来自这个原则如果你也想做个类似的个人小工具建议别急着加功能先把自己最常用的那个动作做到极致的简单剩下的自然会慢慢长出来。
