go的const分组是类型继承和iota重置的边界：省略赋值时继承上一行的类型与值来源（iota或字面量），多块间iota不延续但类型易混淆，须按语义分组隔离。
Go 的 const 分组不是语法糖，而是类型继承和 iota 行为的触发边界——写错位置，值没变，类型却悄悄变了。
const() 块里省略值时到底继承什么
在 const 块中，某行省略赋值（比如只写 ModeUDP），它不会无条件继承上一行的值或类型。真正起作用的是：上一行是否用了 iota，以及是否显式写了类型或非 iota 表达式。
- 如果上一行是
ModeTCP = iota，后续省略行会继承iota的递增值，类型默认为int - 如果上一行是
ModeHTTP = "http"（字符串字面量），后续省略行（如ModeHTTPS）会继承string类型，值变成"http"的副本，不是数字 - 混用时别依赖“自动推导”：显式写
ModeHTTP string = "http"，否则跨包传参可能因类型不匹配静默失败
多个 const 块之间 iota 不延续，但类型容易串
iota 每次遇到新的 const 关键字就重置为 0，这点很明确。但开发者常忽略的是：不同 const 块之间虽不共享 iota，却可能因变量名重复、类型隐含导致语义混淆。
-
const ( A = iota; B )→A=0, B=1（int） -
const ( C = iota; D )→C=0, D=1（也是int，但和上面无关） - 危险点在于：如果第一个块末尾加了
E string = "x"，而第二个块开头又用F省略赋值，它不会受前一块影响——但人容易误读成“接着数”，结果发现F是int而E是string，传参时编译报错
分组不是为了省代码，而是隔离类型和语义
Uber 规范强调：只把逻辑强相关的常量放一组。把数据库配置和 HTTP 状态码硬塞进同一个 const()，看似省了一行 const，实则埋下两处隐患：
- 类型污染：一个块里既有
int（状态码）又有string（DB host），中间一旦插错行，后续省略值的常量类型全乱 - 可维护性差：改 DB 端口要扫完整个块，生怕误动了状态码的
iota偏移 - 正确做法：
const块按用途切分，中间空一行，比如先写StatusOK = 200组，再空行，再写DBHost = "localhost"组
字符串常量转 []byte 别在 const 块里“预分配”
有人想“优化”，在 const 块里写 MyJSONBytes = []byte(MyJSON) ——这直接编译失败，因为 []byte(...) 是运行时操作，不能出现在常量表达式中。
-
const MyJSON = `{ "id": 1 }`✅ 合法，纯编译期字面量 -
var MyJSONBytes = []byte(MyJSON)✅ 推荐，在包级变量声明，只分配一次 -
json.Unmarshal([]byte(MyJSON), &v)❌ 高频调用时每次分配新 slice，底层内存虽只读，但逃逸分析仍视为可变数据 - 极端场景需零拷贝：用
unsafe.Slice(unsafe.StringData(MyJSON), len(MyJSON))（Go 1.20+），但仅限你完全掌控 API 是否接受这种 slice
最常被跳过的细节是：const 块内类型继承规则不报错，字符串转 []byte 的分配行为也不报错——它们安静地待在代码里，直到压测时 CPU 突然升高，或者跨包调用时类型不匹配才暴露出来。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
