%v输出结构体仅显示字段值如{123 "hello" true}，%+v则显示字段名和值如{id:123 name:"hello" active:true}，调试时更直观。
Printf 格式化输出时，%v 和 %+v 的区别到底在哪
用 fmt.Printf 打印结构体，不加 + 就只能看到字段值，加了才能看到字段名——这是最常被忽略的调试细节。
-
%v输出结构体时只显示字段值，顺序固定但无标识，比如{123 "hello" true} -
%+v会带上字段名，变成{ID:123 Name:"hello" Active:true}，调试时省去翻定义的时间 - 嵌套结构体也生效，但不会自动展开指针目标（
*T还是显示&{...}），想看内容得用%+v配合*t解引用 - 注意
%#v是另一种路子：输出 Go 语法风格的字面量，适合生成测试数据，但可读性反而下降
Scanf 系列函数读不到换行符，输入卡住怎么办
fmt.Scanf、fmt.Scanln、fmt.Scan 行为差异极大，卡住往往是因为没搞清它们怎么处理空白符。
-
fmt.Scan跳过所有开头空白（空格、制表、换行），直到遇到非空白字符才开始读，结尾空白全丢弃——适合读单词或数字，但无法读带空格的字符串 -
fmt.Scanf("%s", &s)同样只读到第一个空白，不是整行；想读一行得用fmt.Scanln，但它要求输入以换行结束，且不吞掉末尾换行，如果用户输完按回车，它能读，但如果管道输入没换行就阻塞 - 真正稳读一行的写法是
bufio.NewReader(os.Stdin).ReadString('\n')，fmt.Scan系列根本不该用于行输入场景 - 如果坚持用
Scanf，记得格式动词后加空格，比如fmt.Scanf("%d ", &n)，否则下一个Scanf可能直接读到残留换行而返回 0
Printf 中 %d、%v、%T 混用容易引发类型误判
Go 是静态类型语言，但 fmt.Printf 的格式动词不校验实际参数类型，错配时行为出人意料。
- 对
int64用%d没问题，但对uint64用%d会输出负数（符号位被当有符号解释）——必须用%d配int类型，%v更安全 -
%v对接口类型输出的是动态值，不是底层类型；想看真实类型用%T，比如var x interface{} = 42; fmt.Printf("%T", x)输出int - 浮点数别用
%d强转，fmt.Printf("%d", 3.14)编译不过；但fmt.Printf("%v", int(3.14))可以，只是截断不四舍五入 - 自定义类型如果实现了
String() string方法，%v和%s都会调它，但%#v不会——这点常被用来控制日志精度
Scanf 输入缓冲区残留导致后续读取异常
连续调用 Scanf 或混用 Scan 和 ReadString 时，标准输入缓冲区里藏着看不见的换行，是多数“输入跳过”问题的根因。
立即学习“go语言免费学习笔记（深入）”；
-
fmt.Scanf("%d", &n)读完数字后，用户敲的回车还留在缓冲区；紧接着fmt.Scanln(&s)会立刻读到空行，s变成空字符串 - 清缓冲区不能靠
fmt.Scanln()多读一次，因为如果缓冲区真没东西它就又阻塞；稳妥做法是用bufio.NewReader(os.Stdin).Discard(1)清掉一个字节，或更干脆地统一用ReadString('\n')+strings.TrimSpace - 从文件或管道读时这个问题更隐蔽：
echo -n "123" | go run main.go会让Scanf("%d")一直等换行，而Scan能正常退出——因为Scan不依赖换行作为结束信号 - 所有
Scan*函数返回成功读取的项数，务必检查返回值是否等于预期个数，否则可能部分变量根本没赋值，还是旧值
