Todo结构体应定义为导出字段的int64 ID、time.Time时间戳及JSON序列化标签，避免字符串存时间或int ID溢出，并分离数据与行为。
怎么定义 Todo 结构体才不容易改崩
Go 里结构体不是随便写个 type Todo struct 就完事的。字段要不要导出、用指针还是值、时间字段用 time.Time 还是字符串，直接影响后续所有 CRUD 的健壮性。
常见错误：把 ID 设成 int，结果加到第 2147483647 条就溢出；或用 string 存时间，导致排序错乱、JSON 序列化失败。
-
ID用int64（哪怕现在只存几十条，留余量） - 所有字段首字母大写（导出），否则命令行解析或 JSON 输出时会丢数据
-
CreatedAt和UpdatedAt必须是time.Time，别存字符串——time.Now()直接赋值，序列化时加json:"created_at"` + `time_format:"2006-01-02T15:04:05Z"标签即可 - 别在结构体里塞方法（比如
MarkDone()），命令行逻辑应保持纯数据操作，方法放单独文件或包里更易测
用 flag 包解析命令行参数时为什么老报 “flag provided but not defined”
这是 flag 包最典型的误用：没调用 flag.Parse()，或在它之前用了 flag.String() 以外的函数（比如 flag.Args()），又或者子命令参数没提前注册。
真实场景：你想支持 todo add "buy milk" 和 todo list --done，但一加 --done 就报错。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每个子命令（
add、list、done）要各自初始化独立的flag.FlagSet，不能共用全局flag -
flag.Parse()必须在所有flag.String()/flag.Bool()调用之后、且在读取flag.Args()之前 - 如果用
os.Args[1]手动取子命令名，记得跳过os.Args[0]（程序名），否则第一个参数永远对不上 - 布尔标志默认值设为
false，别依赖隐式零值——显式写flag.Bool("done", false, "...")
文件存储用 JSON 追加写入为什么总丢数据
直接 os.OpenFile(..., os.O_APPEND) 然后 json.NewEncoder().Encode()，看似省事，实际会把多个 JSON 对象连在一起，变成非法 JSON（如 {"id":1}{"id":2}），下次读就 invalid character 报错。
这不是 Go 的问题，是 JSON 本身不支持“流式追加”。你得把整个数据当一个数组来维护。
- 读取时：用
os.ReadFile()一次性读全，json.Unmarshal()成[]Todo切片 - 写入时：修改切片后，再用
json.MarshalIndent()整体写回文件（覆盖，不是追加） - 小数据量（
- 写文件前先
os.WriteFile(tmpPath, data, 0644)，再os.Rename()原子替换，避免写到一半崩溃导致数据全丢
删除和更新操作怎么避免 ID 错位或静默失败
用户输入 todo rm 5，但实际第 5 条已被删过，或 ID 是 5 的记录根本不存在——这时候返回 “not found” 还是沉默跳过？静默失败会让用户怀疑自己按错了，必须明确反馈。
另一个坑：用切片下标删（todos[4] = todos[5:]...），结果 ID 和索引混淆，删了第 5 行却删掉 ID=6 的那条。
- 所有操作都基于
ID字段查，不是基于切片位置。遍历[]Todo找todo.ID == targetID - 删完用
append(todos[:i], todos[i+1:]...)拼新切片，别用copy()或手写循环——容易越界或漏项 - 更新时先查是否存在，不存在就 return error；存在才改字段并重写文件，别只改内存
- 命令行输出统一用
fmt.Fprintln(os.Stderr, "error: ...")报错，正常输出走os.Stdout，方便管道和脚本处理
文件 I/O 和命令行解析这两块最容易藏 bug，尤其是多步骤操作（比如“标记完成+刷新列表”合在一个命令里）时，中间出错没 rollback，状态就歪了。宁可拆成两个命令，也别为了“顺手”牺牲确定性。
