"Lucas_coming"看起来像是一个名叫 Lucas 的人正在赶来的路上，但在开发者眼里，它只是一个项目的代号——一个功能极简的跨平台专注工具，核心就三件事：待办清单、番茄钟、每周统计。名字里那个 coming 是故意的：那个周末深夜我满脑子都是"快做完了"四个字，于是在仓库初始化页面敲下了这个代号。后来它跟我整整两个月，期间经历了三次推倒重来、一次差点放弃，以及连续五个晚上的打包发布噩梦。
这篇文章不是产品软文——这个工具到目前为止也没有多少用户。我想做的只有一件事：完整复盘一个代号里带"coming"的项目，是怎么从模糊想法一路走到可以发布的状态。适合谁看？适合手里同样有一个"快好了"很久、却迟迟不敢说"做完了"的独立开发者和业余项目爱好者。里面没有宏大叙事，只有代号命名、功能收敛、技术选型、踩坑记录和发布清单这些实在的东西。
1. 代号不是随便起的：Lucas_coming 是怎么来的
1.1 为什么项目需要代号，而不是直接想产品名
独立开发者开一个新项目，最常见的卡点往往不是技术选型，而是"这个项目到底叫啥"。我见过有朋友在群里讨论产品名讨论了一周，代码一行没写；也见过有人先起了个气势磅礴的名字，做完功能发现产品和名字完全不匹配，又灰溜溜地改掉。产品名承载的是品牌定位、用户认知、商标风险，这些对一个还没跑通需求的项目来说太重了，过早定产品名，大概率会被一堆命名约束拖住。
我的习惯是：产品名可以慢点定，但项目代号必须在一开始就给出来。代号的价值不在于品牌，而在于沟通和记录。"Lucas_coming"这个代号在后来的 commit 记录里长这样：fix(Lucas_coming): 修复周统计跨天计算错误、feat(Lucas_coming): 支持任务拖拽排序。任何人扫一眼提交历史，就知道这批改动属于哪个项目，完全不用额外解释。代号相当于项目在开发期的一个临时身份，它只需要满足一个条件——让开发者在漫长的开发周期里，每次看到都不反感。
代号怎么起？我自己常用的来源只有三个：随手敲的一串字符，但必须好读好记；最近循环播放的某首歌、某本书里的一个意象；一个带有状态暗示的后缀，比如 coming、wip、alpha。第三种最危险，也最真实。很多项目代号里藏着开发者自己都没意识到的心理状态。"Lucas_coming"里的 coming 就是这种状态的外化——它准确反映了当时那个项目在作者心里的位置：已经开始了，即将完成，但还没完成。
后来我意识到，"即将完成"这四个字，恰恰是独立开发项目最容易烂尾的阶段。功能已经能跑，界面还算能看，但离发布还差着打包、签名、文档、兼容性测试这一堆"看不见的收尾工程"。说"快好了"的时候，大脑会默认任务接近完成，不自觉地降低投入；而真正进入收尾，才会发现每一个环节都比写功能更折磨人。
1.2 代号里的"未完成感"，会影响你的开发状态
"Lucas_coming"这个代号救过我，也差点坑死我。说它救过我，是因为每次打开仓库看到"coming"这个词，我都会被提醒：这个项目还欠着一笔债。它像一个贴在显示器边缘的便利贴，不断把"未完成"这个事实推到眼前。有一阵子我确实靠这个状态保持节奏——每天晚上至少打一条提交，确保代号里的 coming 有资格继续存在。
说它差点坑死我，是因为"未完成感"会滋生拖延。人对"即将结束"的事情有一种天然的松懈：既然明天就能好，那今天先歇了吧。这种心态一天天地累积，"coming"就从"即将完成"滑动成了"无限延期"。那两个月里，我至少有三次打开仓库写了半个小时代码又关掉，理由是"反正快好了，明天再集中处理"。结果"明天"变成了五天后。
这段经历让我总结出一个关于代号的实用建议：第一阶段可以用带"coming/wip"的代号，因为它的催促作用是真的；但要在项目进入收尾期之前把它换成一个中性代号。换代号的时机，最好和首次发布计划绑定在一起——发布前改一次名，成本最低，影响范围内只有你自己。
代号选得对不对，可以对照这个自查表：
| 检查项 | 好的代号 | 坏的代号 |
|---|---|---|
| 好读好记 | 三个音节以内 | 一串随机大小写缩写 |
| 状态暗示 | 中性或完成态 | coming / soon / tmp |
| 输入方便 | 打英文很快 | 需要频繁切换大小写 |
| 有辨识度 | commit 里一眼认出 | 和另一个项目重名 |
| 品牌冲突 | 搜索时无同名大产品 | 已有知名品牌同名 |
2. 功能收敛：把"什么都想做"砍成"只做三件事"
2.1 需求从五行备忘录开始，砍掉了最诱人的云同步
"Lucas_coming"的第一版需求，是我在手机备忘录里写的，一共五行：能快速添加待办，优先级只有"今天/以后"两档；点击开始后进入专注计时，计时期间切走就提示一次，不做强制拦截；每天结束给一句话总结；不要账号；暂时不要云同步。
这五条决定了项目的全部边界，也让这个项目没有在第三周就死掉。砍得最痛的是云同步。做跨平台工具，云同步几乎是默认标配——换一台电脑数据就没了，这像在对用户说"我只配在一台机器上用"。但云同步意味着账号体系、服务端存储、多端冲突处理、隐私政策、数据删除接口，每一项都是按周计算的投入。对一个还要上班、只能晚上和周末写代码的人来说，这五条足以让项目延期一倍以上。
云同步没有完全砍掉，而是换成了一个折中方案：提供"导出/导入 JSON 文件"作为手动迁移通道。用户可以在旧机器上导出一份数据，在新机器上导入。这个方案只花一个周末就做完了，它保留了"数据可以带走"的底线，同时避开了账号体系的整个泥潭。软件功能的价值不能只算"做了多少"，还要算"省下了多少维护量"。
同样被砍掉的还有：自定义铃声、任务的重复规则、多级标签、统计图表的维度筛选。砍掉它们的理由不是技术上难，而是每加一个功能都意味着主界面多一个入口，多一个需要向用户解释的词。第一版的核心卖点是"极简"，所有指向"长期留存"的功能，都应该留到有真实用户反馈之后再做。
2.2 技术选型：选了 Tauri 而不是 Electron 的真实体感
工具层面的第一个大决策是跨平台框架。做跨平台桌面应用，第一反应通常是 Electron：社区成熟、资料多、踩坑经验满天飞。我一开始也搭了一个 Electron 原型，跑了三天后放弃，原因来自三个非常具体的痛点。
第一是安装包体积。同一个 React 前端，Electron 打包出来普遍在 80MB 以上，Tauri 可以压到 5MB 左右。对一个主打"轻量极简"的工具，用户下载要等一分钟本身就是产品缺陷。第二是内存占用。Electron 应用常驻后台的内存占用通常在 200MB 以上，而这款工具的典型使用场景是：开着它专注写代码。我不希望一个待办工具比代码编辑器还吃内存。第三是技术栈统一：前端用 React，后端用 Rust 的一个轻量壳，双方通过命令通道通信，各司其职，编译产物更可控。
但选 Tauri 是有代价的。最大的代价是文档量少一个数量级，很多 Electron 里一行代码能解决的问题，在 Tauri 里需要写配置、翻源码、甚至自己封装插件。其次是跨平台行为不一致，这个放到下一章细讲。先把对比表放出来，方便后来者做判断：
| 对比项 | Electron | Tauri |
|---|---|---|
| 安装包体积 | 80MB 起步 | 5MB 左右 |
| 常驻内存 | 200MB 以上 | 50MB 左右 |
| 文档与社区资料 | 极其丰富 | 偏少，常翻源码 |
| 跨平台一致性 | 高，自带运行时 | 依赖系统 Webview，差异多 |
| 系统能力调用 | 门槛低 | 需要理解后端生命周期 |
| 适合场景 | 复杂桌面应用、快速迭代 | 轻量工具、偏原生体验 |
这张表不是想说谁好谁差，而是"体量匹配"问题："Lucas_coming"是一个功能三件套、界面不过五屏的小工具，用 Electron 属于杀鸡用牛刀，用 Tauri 则刚好。而且选型不是一次性的——如果功能三件套以后长成了功能八件套，Tauri 的后端仍能继续扩展；反过来，如果当初选 Electron，体积和内存的问题会一直跟着产品长大。
2.3 数据模型：把 SQLite 用在一个"本可以不用"的地方
这个工具的数据量很小，理论上用 JSON 文件就够。我仍然选了 SQLite，核心原因是统计查询的迭代速度。如果以后要加"本周专注分布""任务完成率""连续专注天数"这类聚合查询，用 JSON 就必须把全部数据读进内存自己算，而 SQLite 一条 SQL 就解决了。
数据模型只建了两张表，简单到不能再简单：
CREATE TABLE tasks ( id TEXT PRIMARY KEY, title TEXT NOT NULL, due TEXT, -- 'today' 或 'later' done INTEGER DEFAULT 0, created_at TEXT NOT NULL DEFAULT (datetime('now')) ); CREATE TABLE focus_sessions ( id TEXT PRIMARY KEY, task_id TEXT, started_at TEXT NOT NULL, minutes INTEGER NOT NULL, FOREIGN KEY (task_id) REFERENCES tasks(id) );两个细节值得特意写出来。第一个是时间字段全部用 ISO 8601 字符串，不用时间戳。本地优先应用的数据要支持导出、备份和恢复，人类可读的时间格式在出问题时更容易排查，而且 SQLite 的 datetime 函数可以直接处理字符串，不需要额外转换。第二个是数据库文件放在系统的应用数据目录，而不是项目目录。开发版和正式版在这个问题上完全不通用：开发时随手写在相对路径，打包后第一次启动会因为找不到文件而直接报错。正确定位方式是查当前操作系统暴露的应用数据目录，然后在首次启动时执行建表逻辑，文件不存在也要能正常冷启动。
3. 三个差点让项目夭折的夜晚
3.1 在 Windows 上关闭窗口，整个应用直接消失了
这个 bug 是发布前第四天发现的，过程值得完整复盘。
我在 macOS 上开发和测试时，"关闭窗口"这个动作意味着应用退到后台，Dock 图标还在，计时器还在走。于是代码里很自然地没有做"关闭窗口时保存数据"的处理——因为在 macOS 上，关窗根本不会退出应用。第一次在 Windows 虚拟机上测试时，我点击关闭按钮，预期是应用回到托盘继续计时，结果窗口直接消失，进程直接退出，正在进行中的专注 session 没来得及写进数据库，全部丢失。那一刻我才意识到：macOS 的"关窗不离场"只是平台习惯，Windows 的默认行为才是最直白的——关窗就是退出。
排查链路是这样的：先在 Windows 上复现，添加任务、开始专注计时、点关闭按钮、重新打开应用，发现 session 表里没有任何记录。接着判断是"退出前没保存"还是"保存了但没读出来"：我在数据库里临时加了一张调试日志表，每次计时结束回写一条日志，再关窗测试，发现日志表同样为空，说明是前者。最后修复方案是拦截窗口关闭事件，在 Windows 上把"关闭窗口"重定义为"隐藏到托盘"，只有从托盘菜单选择"退出"才真正销毁进程。
appWindow.onCloseRequested(async (event) => { if (process.platform === 'win32' && !isExiting) { event.preventDefault(); appWindow.hide(); } });这个 bug 的本质不是代码写错，而是"在哪个平台写代码，就会不自觉地以那个平台的交互习惯作为默认值"。独立开发者的主力开发机通常只有一个操作系统，跨平台兼容性测试一定不能留到最后几天才开始。
3.2 托盘图标：macOS 一团黑，Windows 糊成一片
第二个坑是系统托盘。这个功能本身很简单：最小化到托盘，右键菜单提供"显示主窗口/退出"两个选项。但它在不同平台上的表现完全不同，开发时没做针对性适配，发布前测试直接翻车。
macOS 的菜单栏图标要求是"模板图片"，也就是只有黑白两色、带透明背景的图，系统会按当前菜单栏颜色自动调整显示效果。我一开始放了一张彩色图标，结果在 macOS 菜单栏上变成一团黑乎乎的方块。Windows 的托盘图标带两种状态：正常和激活（鼠标滑过时），如果图标尺寸不足，Windows 会强行缩放，显示效果就是一坨模糊的色块。最稳妥的做法是准备两组不同尺寸的 PNG，分别给 macOS 和 Windows 用。
Linux 这边我直接放弃了托盘功能。Tauri 的托盘在 Linux 上依赖桌面环境，不同发行版的行为差异极大，强行做只会让"支持 Linux"变成"在所有 Linux 上都表现得很奇怪"。最终策略是：Windows 和 macOS 启用托盘，Linux 上检测到无托盘环境时禁用托盘入口，正常显示主窗口。
这个坑给独立开发者的教训是：不要把"跨平台"理解成"写一次跑三处"，要理解成"同一套前端逻辑，三个完全不同的壳"。凡是涉及操作系统原生交互的模块——托盘、菜单栏、窗口行为、文件对话框——都得单独过一遍。
3.3 SQLite 报 database is locked，数据差点没救回来
第三个坑出在数据层。某天晚上我在连续快速创建任务时，应用偶尔会弹出 database is locked 的报错。报错场景不确定，有时是主页和统计页同时初始化，有时是两个快速的写入操作挤在一起。
排查链路如下：第一反应是并发写入冲突，检查代码发现每个页面都自己打开了一个数据库连接，页面级连接没有统一管理。先改成单例模式，统一通过一个连接操作数据库，报错频率下降，但没有完全消失。进一步定位后发现，统计页里有一个定时器定期做聚合查询，这个查询和主界面的写入操作触发了 SQLite 文件锁竞争。解决方案是开启 WAL 模式，让读写并发不再互相阻塞：
PRAGMA journal_mode=WAL; PRAGMA synchronous=NORMAL;WAL 模式解决读写锁竞争之后，database is locked 彻底消失了，但它有一个新的副作用：数据目录下会多出-wal和-shm两个文件。如果用户备份时只拷贝了主数据库文件，恢复后会报数据库损坏，或者直接看不到最近几天的记录。正确做法是：备份时把-wal文件一起拷贝，或者备份前先执行一次PRAGMA wal_checkpoint，把 WAL 里的内容合并进主库。我最终在"导出数据"功能里先执行 checkpoint 再复制文件，从根上规避了这个问题。
这三个坑有一个共性：它们在开发机上几乎不会暴露，只有换到真实用户的操作环境才现出原形。其实每一个坑背后都对应一个容易忽略的假设——默认所有平台行为一致、默认用户会用开发机的方式操作、默认数据库自己管好自己。把这些假设翻出来，很多灵异问题都能对号入座。下面这个速查表就是当时的排查笔记：
| 症状 | 根因 | 处理 |
|---|---|---|
| 关窗后计时丢失 | 关闭即退出是 Windows 默认行为 | 捕获关闭事件，隐藏到托盘 |
| 托盘图标显示异常 | 各平台对图标格式要求不同 | 按平台准备对应格式与尺寸 |
| 高频读写报锁错误 | 多连接并发 + 没开 WAL | 单例连接 + WAL 模式 |
| 恢复备份后怀疑损坏 | 漏拷贝 -wal 文件 | checkpoint 后再备份 |
4. 从 coming 到可发布：上线前的五个检查点
4.1 版本号先定 0.1.0，别一上来就 1.0.0
发布前第一件事是定版本号。很多独立开发者喜欢把第一个能跑通的版本定成 1.0.0，仿佛这代表"功能做完了"。我的建议是：第一个对外发布的版本用 0.1.0。这不是谦虚，而是管理预期。0.1.0 意味着你明确承认产品还不稳定，用户遇到问题时预期是"正常情况"，反馈语气会更友好；1.0.0 意味着你已经对外承诺了稳定和完整，第一次启动就崩溃的话，后面解释什么都像在辩解。版本号本质上是一种预期管理工具，别让一个数字成为产品口碑上的负担。
4.2 安装包签名：个人开发者最难受的一道坎
Windows 平台对未签名的 exe 有 SmartScreen 拦截。用户第一次运行会看到"Windows 已保护你的电脑"，必须点"更多信息"，再点"仍要运行"才能放行。对这个小小的警告，小白用户的反应大概率是直接关掉页面，顺手给产品扣一个"不安全"的帽子。
代码签名证书需要组织信息，个人开发者不一定办得下来。我的妥协方案是：先用自签名证书完成开发和内测；发布版暂时接受 SmartScreen 告警，但在发布说明里写明原因；等产品有铺量需求时，再评估办理合规的企业级签名证书。这里有个容易误判的细节：即使有了证书，第一次签名的应用首次运行时 SmartScreen 仍可能拦截，因为 Windows 的信誉体系需要一个"被足够多用户安装过"的积累过程，这是机制本身，不是签名搞错了。
4.3 发布前自查清单：每一行都要在新机器上过一遍
开发机上验证一百遍，都不如在一台干净的新机器上跑一遍真实安装流程。你会发现很多在开发机上永远不会出现的问题，在新机器上第一次启动就原形毕露——因为开发机积累了半年的缓存、依赖、环境变量，它们把问题都悄悄掩盖了。清单的目的不是追求完美，而是把"发布后用户替我发现问题"变成"发布前我自己发现问题"。
| 检查项 | 为什么必须查 |
|---|---|
| 全新机器首次安装并启动 | 数据目录不存在时的冷启动逻辑 |
| 断网状态下打开应用 | 是否有网络请求导致白屏或卡顿 |
| 窗口在 1366x768 下的显示 | 最小分辨率下布局是否完整 |
| 关闭窗口后从托盘恢复 | 计时数据是否完整保留 |
| 跨天边界（23:59-00:01）的统计 | 周统计跨天计算的正确性 |
| 导出数据后导入到新机器 | 备份恢复通道是否真的可用 |
这些检查项看起来机械，但每一个背后都有真实翻车记录。跨天边界那条，第一次测试就发现统计页把"昨天的最后一分钟"排到了"今天的开始"，因为排序字段用了date而不是datetime。这个问题只在午夜前后才会触发，开发时完全注意不到。
4.4 README 和 Release Notes：它们比代码更影响留存
源码之外的"用户入口"同样重要。用户下载应用之前，先读到的是 Release Notes 和 README，不是你的代码。第一版 README 我写了四遍：第一遍是介绍自己和项目缘起，没用，用户不关心；第二遍罗列全部功能，太长，没人读完；第三遍采用"一句话定位 + 截图 + 三步上手 + 三条 FAQ + 更新日志"的结构，才终于勉强能用。
一个合格的工具类 README 只需要回答四个问题：这是什么？能干什么？怎么用？出了问题怎么办？顺序不能乱，每多扯一句题外话，就多一次让用户关闭页面的机会。Release Notes 也一样，第一版我只写"修复若干问题""优化体验"，后来发现这种写法毫无价值，用户根本不知道更新了什么。正确的写法是按用户能感知的变化分类——新增功能、体验改进、问题修复、已知问题，每条都写"为什么"而不是只写"做了什么"。
5. 一个带"coming"的代号，最后教会了我什么
5.1 用户对"coming 型产品"的真实反应
发布之后，我观察到一个有点好笑的现象：不少用户看到"Lucas_coming"这个名字，第一反应是"这是个测试版吧"，还有朋友反复确认"你的产品到底做完了没"。
"coming"这个词在用户认知里带着明显的"未完成"标签。对开发者来说，它可能代表谦虚、代表持续迭代；但对用户来说，一个名字里带着"即将到来"的产品，天然会降低信任度。如果产品想长期经营，代号转正最好在第一个稳定版本发布时就完成。判断代号改不改，标准只有一个：除了你之外，还有多少人在用这个名字。如果用户已经把它当作品牌名在社区讨论、在书签收藏，那改名成本会随时间快速上升，与其拖到用户习惯了再改，不如在第一个稳定版就果断一点。
5.2 代号会影响长期维护的心态
"Lucas_coming"这个名字伴随了整个开发周期。每打开一次仓库，都在提醒"这个项目还没做完"；加上连续两个月的"快好了"delay，这种未完成感一度让我不想再打开项目。后来我做了一件很小但很关键的事：把仓库和所有文档里的代号改成了正式的产品名。
那个瞬间最强烈的感受不是不舍，而是如释重负——从"还没做完"变成了"做完了，现在需要维护"。这两种心态消耗的能量完全不同：前者是背债，后者是经营。如果你发现自己在心理上一直无法进入"维护"状态，可以检查一下是不是项目名本身还在给你传递"未完成"的信号。名字看起来只是符号，但它会反复参与你的心理暗示，最终左右你对这个项目的态度。
5.3 如果再起一个代号，我的五条标准
把这次的经验收敛成一张清单，下次开新项目直接照着用：
- 三个音节以内，好读好记。
- 状态中性，避免 coming、soon、tmp 这类词。
- 搜索时不会撞上同名知名品牌。
- 在 commit 信息里有足够辨识度。
- 输入方便，不用频繁切换大小写和符号。
"Lucas_coming"这个代号，正着看是"即将到来"，反着看是一个提醒：完成一个项目的关键，不是把"完成"挂在嘴边，而是把"完成"拆成可以一项项勾掉的检查点，然后真的去勾。
最后再分享一个小技巧：如果你手里也有一个"coming"了很久的项目，先不要急着写更多功能，把它的发布清单列出来——安装、签名、冷启动、文档、备份恢复，每一项标上预计完成时间。你会发现，"快好了"和"真的快好了"之间，往往只差这张清单。对我来说，"Lucas_coming"已经从项目代号退役成了仓库历史里的一个 tag，它提醒我：代码可以一直写下去，但产品必须有一个"从 coming 变成 here"的时刻。
