根本原因是PATH未正确配置或Shell配置未生效；macOS/Linux需在~/.zshrc或~/.bash_profile中添加export PATH=$PATH:/usr/local/go/bin并source，Windows需手动将Go的bin目录（如C:\Go\bin）加入系统Path环境变量，再新开终端执行go version验证。
Go 环境安装后 go version 报错或找不到命令
常见原因是 PATH 没配对，尤其是 macOS 或 Linux 下用 tar 解压二进制包后，只加了 /usr/local/go/bin 却漏掉当前 shell 的配置文件重载。
- 确认 Go 安装路径是否正确：运行
ls /usr/local/go/bin/go（macOS/Linux）或where go（Windows PowerShell） - Linux/macOS：把
export PATH=$PATH:/usr/local/go/bin加到~/.bashrc或~/.zshrc，然后执行source ~/.zshrc - Windows：在「系统属性 → 高级 → 环境变量」中检查
PATH是否包含 Go 的bin目录（如C:\go\bin），改完需重启终端 - 别用包管理器混装（比如同时用
brew install go和手动解压），容易冲突
用 os.WriteFile 测磁盘写入速度但结果虚高
默认写入是 buffered 的，os.WriteFile 会先写进内核页缓存，返回时数据未必落盘，测出来的是内存带宽，不是真实磁盘性能。
- 要测真实写入，必须调用
file.Sync()强制刷盘，否则WriteFile返回快不代表磁盘快 - 小文件（WriteFile 会放大 syscall 开销，建议单次写入 ≥4MB，减少系统调用次数
- 避免用
tempfile测试——某些 tmpfs 或 SSD 缓存策略会让结果失真，应指定明确路径如/tmp/test-write.dat - 示例关键片段：
f, _ := os.OpenFile("/tmp/test-write.dat", os.O_CREATE|os.O_WRONLY, 0644) f.Write(data) f.Sync() // 必须加 f.Close()
读取测试中 io.Copy 比 os.ReadFile 更准的原因
os.ReadFile 会一次性把整个文件加载进内存，对大文件（>1GB）可能触发 GC 或 OOM；而 io.Copy 配合 bufio.NewReader 可控缓冲区大小，更贴近真实应用读取行为。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 读取时建议用固定 buffer（如 1MB），避免默认 4KB 太小导致 syscall 过多，也避免太大浪费内存
- 关闭文件前务必
file.Close()，否则后续重复测试可能因文件句柄耗尽失败 - 别忽略
os.O_DIRECT（Linux）或syscall.O_DIRECT——它绕过页缓存，但需要对齐（buffer 和 offset 都是 512B 倍数），普通测试不推荐，容易出错 - 简单读取示例：
f, _ := os.Open("/tmp/test-write.dat") defer f.Close() buf := make([]byte, 1024*1024) io.Copy(io.Discard, bufio.NewReaderSize(f, len(buf)))
Windows 下测 SATA SSD 时 time.Now() 精度不够
Windows 默认 time.Now() 分辨率约 15ms，测小文件（如 10MB 写入）误差可能超 ±20%，根本没法比对性能差异。
立即学习“go语言免费学习笔记（深入）”；
- 改用
runtime.nanotime()获取纳秒级时间戳，再换算成秒，精度足够 - 注意：不要用
time.Since()包裹整个操作——它内部仍基于time.Now()，同样受系统时钟分辨率限制 - SSD 测速前先清空页面缓存（Linux 执行
echo 3 | sudo tee /proc/sys/vm/drop_caches），Windows 无等效命令，可重启或用RAMMap工具清空 - 多次运行取中位数，单次结果波动大，尤其机械硬盘或有后台 IO 干扰时
