因为原生 flag 包难以维护多子命令、选项解析、帮助生成、补全和错误处理，而 spf13/cobra 提供自动解析、嵌套命令管理、内置 help/alias/short-flag 支持及 bash/zsh 补全。
为什么不用 flag 包直接解析，而要用 spf13/cobra
因为 todo add "buy milk"、todo list --done、todo rm 3 这类多子命令 + 带选项的 CLI，用原生 flag 写起来很快会失控：参数绑定松散、帮助文本要手写、子命令嵌套难维护、补全和错误提示基本为零。
spf13/cobra 是事实标准，它把每个子命令抽象成 Cobra.Command 实例，自动处理解析、help 生成、别名、短选项合并（如 -d → --done），还支持 bash/zsh 补全。
实操建议：
- 用
cobra-cli工具初始化项目：cobra-cli init && cobra-cli add add list rm - 每个
*cobra.Command的RunE字段返回error，Cobra 会自动转成非零退出码和 stderr 输出 - 避免在
init()里做 I/O（比如读配置文件），否则单元测试时无法 mock
数据存哪？JSON 文件比 SQLite 更合适
TODO 工具不需要事务、并发写或复杂查询。用 os.WriteFile 存 JSON 到 $HOME/.todo.json，简单、可读、易调试、Git 友好。
立即学习“go语言免费学习笔记（深入）”；
常见错误现象：多个终端同时 todo add 导致数据丢失 —— 因为没加文件锁。
实操建议：
- 用
flock（Linux/macOS）或syscall.LockFileEx（Windows）对数据文件加写锁，不是靠重命名或临时文件模拟 - 结构体字段用
json:"id,string"把 ID 转成字符串，避免前端（比如 TUI）误当数字处理溢出 - 不要每次操作都
os.ReadFile+json.Unmarshal全量加载；先stat检查文件是否存在，空文件直接用默认切片初始化
todo list --filter=overdue 这种过滤逻辑怎么组织
过滤不是硬编码在 listCmd.RunE 里，而是抽成独立函数，接收原始 []TodoItem 和 *cobra.Command，返回过滤后切片。
这样既方便测试（传入不同数据断言结果），也支持组合过滤：--done --priority=high 就是两个 filter 函数链式调用。
实操建议：
- 定义
type FilterFunc func([]TodoItem) []TodoItem，每个 flag 对应一个 filter：比如doneFilter(cmd)检查cmd.Flags().GetBool("done") - 时间过滤（如
overdue）别用time.Now().Before(item.Due)简单比较，要处理item.Due.IsZero()（无截止时间的 TODO 不参与 overdue 判断） - 输出前统一调用
sort.Slice(items, ...)，按 ID 升序或状态分组，别依赖存储顺序
如何让 todo 支持 shell 自动补全
Cobra 内置补全生成器，但默认只补子命令（add/list/rm），不补具体数据（比如已存在的 TODO ID 或 tag）。要补 ID，得实现 ValidArgsFunction。
容易踩的坑：补全函数里又去读一次 JSON 文件，导致每次按 Tab 都卡顿；或者没处理文件不存在/权限不足，直接 panic。
实操建议：
- 补全函数必须有超时控制（例如
context.WithTimeout(ctx, 200*time.Millisecond)），超时就退化为只补子命令 - 用
cmd.RegisterFlagCompletionFunc("id", ...)给特定 flag 注册补全，而不是全局劫持 - 生成补全脚本后，提醒用户执行：
source ，别假设他们知道要 reload shell
todo rm <tab></tab> 时，能瞬间列出所有可用 ID，且不因磁盘慢、文件损坏或并发写失败而挂住 shell —— 这要求补全路径彻底隔离主流程，有自己的错误降级策略。 
