基于Golang的待办事项(Todo-List)应用_结构体存储与命令行CRUD

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语言免费学习笔记（深入）”；

• 每个子命令（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，状态就歪了。宁可拆成两个命令，也别为了“顺手”牺牲确定性。