Go刷LeetCode核心是避runtime错误、掌握输入输出模型及边界处理：用fmt.Scanf或json.Unmarshal读数组，bufio.NewReader限行读多行，Ints2List/层序建树构造节点，严判空切片与指针非空，复用切片并预分配map容量。
Go 语言刷 LeetCode，核心不是学语法，而是避开 runtime 错误、理解标准输入输出模型、适应题设边界条件——多数人卡在 fmt.Scan 和 strings.Split 的组合上，不是不会写算法。
LeetCode Go 环境的输入怎么读？别用 bufio.Scanner 默认行为
LeetCode 后端用的是单次完整输入流（比如一行数组、多行树序列），但本地测试常误用 scanner.Scan() 循环读到 EOF，导致超时或 panic。
- 数组输入（如
[1,2,3]）：直接用fmt.Scanf配合格式化字符串，或用strings.TrimSpace+json.Unmarshal更稳 - 多行输入（如链表/树的 BFS 序列）：用
bufio.NewReader(os.Stdin)，但必须限制读取行数，不能无脑ReadString('\n') - 空输入或空行：LeetCode 可能传空字符串，
strings.Split("", ",")返回[]string{""}，不是[]string{}，要手动过滤
ListNode 和 TreeNode 怎么快速构造测试用例？
LeetCode Go 模板里只定义了结构体，没给构造函数，手写嵌套字面量极易出错，尤其带 nil 子节点时。
- 链表：写个辅助函数
func Ints2List(nums []int) *ListNode，内部用for迭代，比手写&ListNode{Val: 1, Next: &ListNode{...}}少出三层括号错误 - 二叉树：用层序数组（含
nil占位）转树，关键点是用queue模拟 BFS 建树，别用递归——下标计算容易越界 - 注意：LeetCode 的
TreeNode定义里字段名是Val/Left/Right，大小写敏感，写成val直接编译失败
为什么本地跑对了，提交却报 runtime error: index out of range？
常见于切片操作和双指针场景，LeetCode 测试用例往往包含极端值（空输入、单元素、全相同值），而本地只测了“看起来合理”的数据。
-
nums[0]前必须检查len(nums) == 0，Go 不做隐式空切片保护 - 快慢指针中，
fast = fast.Next.Next前得确认fast != nil && fast.Next != nil，否则直接 panic - 字符串双指针（如回文判断）：用
rune切片而非byte，避免中文或 emoji 导致索引错位
性能敏感题（如滑动窗口、前缀和）怎么避免切片重分配？
LeetCode Go 默认开启 GC，但高频新建小切片（比如每次循环 make([]int, k)）会拖慢执行时间，尤其在 n=1e5 级别时明显。
- 复用切片：用
res = res[:0]清空而非res = make([]int, 0, cap)新建 - 前缀和数组：直接基于输入长度声明
pre := make([]int, len(nums)+1)，不 append - map 初始化别写
m := map[int]int{}，写m := make(map[int]int, len(nums))减少扩容次数
最难的不是写对算法，是让代码在 LeetCode 那个精简、无调试输出、输入格式诡异的 Go 环境里安静跑完——多一个空格、少一次判空、错一个字段名，就直接报错退出，没机会打日志。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
