filepath.WalkDir 需显式处理权限错误（用 filepath.SkipDir）和软链接（调 Info 判断），后缀过滤用 entry.Name() 而非全路径；统计 Go 行数时跳过空行、// 注释行，清除 UTF-8 BOM，优先用 os.ReadFile 避免 bufio.Scanner 超长行 panic。
filepath.WalkDir 怎么用才不漏文件、不崩
它比 filepath.Walk 更轻、更可控，但默认不递归进 symlink（软链接），也不自动跳过权限错误——这两点最容易导致统计不准或 panic。
- 必须显式传入
filepath.SkipDir处理权限拒绝（比如/proc下某些目录） - 如果想跟随软链接，得自己在
DirEntry上调用Info()判断类型，再决定是否继续 walk（WalkDir默认不 resolve symlink） - 别直接对
entry.Name()做后缀判断——它返回的是纯文件名，不含路径；后缀过滤应基于strings.HasSuffix(entry.Name(), ".go")这类逻辑，而非全路径
统计代码行数时，怎么区分空行、注释行和有效代码行
Go 源码里 // 注释可能出现在行尾，/* */ 可能跨多行，简单按行切分会误判。实际只需关注单行注释和空行，因为 Go 不鼓励块注释写在函数体内部，且 /* */ 跨行情况极少影响行数统计精度。
- 逐行读取时，用
strings.TrimSpace清空首尾空白后再判断：空字符串 → 空行；以//开头 → 注释行 - 不必处理
/*开头的行——这类注释通常独立成段，且真实项目中占比极低；强行支持反而增加状态机复杂度 - 注意 UTF-8 BOM：部分编辑器保存的 .go 文件开头有
\uFEFF，会导致第一行TrimSpace后仍非空；建议先用bytes.TrimPrefix(b, []byte("\xef\xbb\xbf"))清除
为什么用 os.ReadFile 而不是 bufio.Scanner 读单个文件
行数统计本质是计数，不是流式处理；bufio.Scanner 默认缓冲区 64KB，遇到超长行（比如嵌入的 base64 字符串）会报 scanner: too long 错误，而 os.ReadFile 直接整文件加载，配合 bytes.Count 或简单遍历 []byte 更稳。
- 小文件（
- 若真要处理 GB 级单文件（极少见），改用
bufio.NewReader+ 手动找\n字节更合适，但这就脱离“代码行数统计”本意了 - 别用
strings.Split(string(b), "\n")——分配大量小字符串，GC 压力大；直接用bytes.Count(b, []byte("\n"))快且省
filepath.WalkDir 遍历时如何安全过滤目录和文件
过滤逻辑必须放在 WalkDirFunc 回调里做，不能靠外部条件提前 return——因为 WalkDir 的递归控制权在回调返回值手里。
立即学习“go语言免费学习笔记（深入）”；
- 想跳过某个目录（如
vendor或.git），在该目录的DirEntry回调里 returnfilepath.SkipDir - 想跳过某类文件（如测试文件
*_test.go），检查entry.Name()后缀，returnnil继续；不匹配就直接 returnnil，不用额外处理 - 别在回调外层用
if !strings.HasSuffix(...)包裹整个逻辑——那样 walk 还是会发生，只是结果被丢弃，白白浪费系统调用
最易被忽略的是 symlink 处理和 BOM 清洗：前者让工具在容器或 CI 环境里漏掉一部分代码，后者让本地开发统计比 CI 多一行——两个问题都安静，但叠加起来会让团队对“总行数”失去信任。
