不会卡住断点，但会使单步执行变慢、变量展开延迟明显；因delve依赖reflect.valueof构建值视图，嵌套深或字段多时触发大量反射操作，导致ui假死或转圈1–2秒。
Delve 调试器里 reflect.ValueOf 会卡住断点吗？
不会直接卡断点，但会让单步执行变慢、变量展开延迟明显——尤其在 inspect 变量时，VS Code 的 Debug Console 或 Variables 面板调用 reflect.ValueOf 获取字段值，若结构体嵌套深或字段多，就会触发大量反射操作，表现为“点击变量后转圈 1–2 秒”。
这不是 VS Code 本身的问题，而是 Delve 在读取变量运行时状态时，依赖反射构建值视图。它必须调用 reflect.ValueOf、遍历 reflect.StructField、解析 Tag，每一步都带分配和字符串处理开销。
- 字段数 > 20 的 struct，单次变量展开可能耗时 5–10ms（实测 QPS 1k 场景下）
- 嵌套 4 层以上的 map[string]interface{} 或 []interface{}，Delve 会递归反射，极易触发 GC 暂停，导致调试器 UI 假死
- 如果代码里用了
json.RawMessage或interface{}，Delve 默认尝试全量展开，比普通 struct 更慢
launch.json 里加什么参数能缓解反射带来的调试卡顿？
不能靠配置参数绕过反射，但可以限制 Delve 的展开深度和类型范围。关键是在 launch.json 的 dlvLoadConfig 中设置加载策略：
-
"followPointers": false—— 避免自动解引用指针，防止意外展开大对象 -
"maxVariableRecurse": 2—— 控制嵌套展开层数，设为 1–2 足够看请求体顶层字段 -
"maxArrayValues": 5—— 限制 slice/map 显示元素数，避免反射遍历全部项 -
"maxStructFields": 15—— 超出字段数的 struct 只显示前 N 个，跳过 tag 解析和冗余字段
完整片段示例：
"dlvLoadConfig": {
"followPointers": false,
"maxVariableRecurse": 2,
"maxArrayValues": 5,
"maxStructFields": 15
}
为什么在调试器里看 Gin 的 *gin.Context 就特别慢？
因为 *gin.Context 内部持有 map[string]interface{}（如 Keys）、sync.RWMutex、http.Request 等复杂字段，Delve 尝试展开时会逐个调用 reflect.ValueOf 并读取其 Tag 和 Kind。更麻烦的是，http.Request 包含 Body io.ReadCloser，Delve 为安全起见会尝试探测其类型，触发额外反射和接口断言。
- 不要在断点处直接展开
c（即 *gin.Context），改用c.Request.URL.Path或c.Param("id")这类明确路径访问 - 避免在 Watch 表达式里写
c或c.Keys，换成len(c.Keys)或c.Keys["user_id"]这类具体访问 - 如果必须查上下文内容，先用
log.Printf("%+v", c)输出到终端，比调试器展开快一个数量级
调试时还能用 reflect.New 吗？性能影响有多大？
能用，但不建议在调试路径里调用。比如你在断点后手动执行 reflect.New(reflect.TypeOf(User{}))，Delve 会把它当普通表达式求值，而该调用本身就会触发堆分配 + write barrier，不仅慢（比 &User{} 慢 3.8 倍），还会让 GC 压力陡增，进一步拖慢后续所有变量读取。
- 调试中构造临时对象，一律用字面量：
&User{Name: "test"}，而不是reflect.New(...).Interface() - 如果非要测试反射逻辑，把相关代码移到单独的 test 函数里跑，别夹在 HTTP handler 的断点中间
- 注意
reflect.Zero(t).Interface()返回值而非指针，别误当成指针传给需要*T的函数，否则 panic
真正容易被忽略的是：Delve 的变量加载逻辑本身无法关闭反射，你只能控制它展开多少、展开到哪一层。优化重点不在“怎么让反射更快”，而在“让它少做多少事”。
