START HERE
按这条路线完成项目
- 01准备阶段→
第 1 章:先定义完成——需求、边界与验收标准
不急着写代码,先把待办清单 CLI 的用户、命令、数据边界和可验证结果定义清楚。
- 02编码实现→
第 2 章:搭起骨架——任务模型与程序边界
从 Task 数据模型开始,把命令解析、业务动作和文件存储拆成可以独立理解与测试的边界。
- 03编码实现→
第 3 章:让数据留下来——JSON 存储与安全替换
实现文件读取、JSON 编解码和临时文件替换,理解一个小项目也应该认真处理的数据安全问题。
- 04编码实现→
第 4 章:完成核心功能——添加、查看、完成与删除
把四个命令串成完整任务生命周期,并逐个处理空输入、错误编号和不存在任务等边界。
- 05测试验证→
第 5 章:把项目交付出去——测试、构建与复盘
用临时目录完成生命周期测试,再构建跨平台可执行文件,为这个小项目画上可验证的句号。
PROJECT BRIEF
为什么从命令行待办清单开始
第一个项目最重要的不是功能多,而是能够完整走完一次工程闭环:先确认问题,再确定边界,然后编码、保存数据、处理错误、编写测试,最后构建出别人能运行的程序。
待办清单足够小,不需要注册账号、部署数据库或搭建前端;它又不是一道孤立算法题,因为数据需要跨进程保存,命令之间必须保持一致,异常输入也需要得到明确回应。
最终可以运行什么
完成全部章节后,你会得到一个名为 todo 的可执行程序:
todo add 学习 Go 文件操作
todo add 为项目编写测试
todo list
todo done 1
todo delete 2
它默认把数据保存在用户目录的 .xiaoai-todo/tasks.json,也允许通过 TODO_DATA_FILE 指定临时位置。这个小设计让日常使用保持简单,同时让自动化测试不会污染真实数据。
项目结构
examples/go-todo-cli/
├── main.go # 读取环境并启动程序
├── app.go # 命令解析与业务流程
├── task.go # 任务模型和编号规则
├── store.go # JSON 读取与安全替换
└── app_test.go # 生命周期与异常测试
这里没有为了“像企业项目”而堆叠目录。拆分只服务于三个真实边界:用户输入、任务规则和数据存储。
推荐学习方式
先从第一章开始,不要一上来复制完整代码。每章只引入一个新问题,并在结尾给出可执行的检查方式。遇到结果不一致时,先停在当前章节定位,而不是带着错误继续向后。
完成第五章后,再打开仓库中的完整代码对照。你应该能够解释每个文件为什么存在、一个命令怎样流过系统,以及数据写入失败时程序会怎样表现。
学过 Go 基础语法,但还没有独立完成过完整项目的初学者;也适合想练习需求拆解、文件持久化和测试边界的开发者。
单进程 CLI 架构:main 负责装配,App 负责编排命令,Task 表达领域数据,Store 负责 JSON 文件读写;所有依赖均来自 Go 标准库。
当前是单用户本地工具,不提供并发写入、云同步、任务截止时间和多列表功能;这些能力留给后续项目,而不是塞进第一个版本。
WHAT YOU WILL SHIP
项目成果
完整任务生命周期
支持添加、查看、完成和删除任务,覆盖一个待办事项从创建到退出列表的完整过程。
本地 JSON 持久化
数据默认保存在用户目录,并通过临时文件替换降低写入中断导致文件损坏的风险。
自动化验证
使用临时目录测试连续命令和异常输入,不污染开发者电脑上的真实任务数据。
跨平台构建
只使用 Go 标准库,可构建 Windows、macOS 和 Linux 的单文件可执行程序。
验证结果完整实现 4 个命令和 3 组自动化测试;go test ./... 通过,并可构建 Windows、macOS 与 Linux 可执行文件。
OPTIONAL READING
设计笔记
想先完成项目,可以跳过这里;想理解为什么这样设计,再展开阅读。
第一版使用 JSON 文件而不是数据库已确认 · 2026年9月4日
无需外部依赖,数据可直接查看,足以支撑单用户待办清单。
- 选择
- 使用本地 JSON 文件保存任务。
- 代价
- 不适合多进程并发写入和复杂查询,规模扩大后需要迁移存储。
命令解析与文件存储保持分离已确认 · 2026年9月4日
业务流程可以直接传入参数和输出缓冲区测试,职责也更容易理解。
- 选择
- main 只装配依赖,App 编排命令,Store 负责文件。
- 代价
- 文件数量增加,但每个文件只承担一个清晰任务。