Go在Windows下os.Open读取中文路径失败主因是命令行参数编码不匹配：cmd默认GBK而Go期望UTF-8，需用golang.org/x/text/encoding/simplifiedchinese将os.Args[1]从GBK转UTF-8；源文件须存为UTF-8，硬编码路径无问题。
Windows 下 os.Open 读取含中文文件名失败怎么办
Go 标准库在 Windows 上默认用系统 ANSI 编码（如 GBK）解析命令行参数和文件路径，但 os.Open 内部调用的是 WinAPI 的 Unicode 接口（CreateFileW），实际能正确处理 UTF-16 路径——问题往往出在你传进去的字符串本身不是 UTF-8 源头生成的。
常见错误现象：open 测试.txt: The system cannot find the file specified.，而文件明明存在、命令行里也能 dir 看到中文名。
- 确认你的 Go 源文件保存为 UTF-8 编码（VS Code / GoLand 默认是，记事本容易存成 GBK）
- 避免从非 UTF-8 来源拼接路径：比如从
os.Args读取时，Windows 控制台默认是 GBK，需手动转码（见下一条） - 直接硬编码中文路径（如
os.Open("测试.txt")）只要源码是 UTF-8 就没问题
从 Windows 命令行读取 GBK 参数时如何转成 UTF-8
Windows 控制台（cmd.exe）默认使用系统区域设置的 OEM 代码页（通常是 GBK），os.Args 拿到的是乱码字节，不能直接当 UTF-8 字符串用。
你需要显式用 golang.org/x/text/encoding/simplifiedchinese 转换：
立即学习“go语言免费学习笔记（深入）”；
import (
"os"
"golang.org/x/text/encoding/simplifiedchinese"
"golang.org/x/text/transform"
"io/ioutil"
)
func main() {
if len(os.Args) < 2 {
return
}
// os.Args[1] 是 GBK 字节，需解码
decoder := simplifiedchinese.GBK.NewDecoder()
filename, _ := ioutil.ReadAll(transform.NewReader(
bytes.NewReader([]byte(os.Args[1])),
decoder,
))
os.Open(string(filename)) // 这才是正确的 UTF-8 字符串
}
注意：ioutil 已弃用，生产环境请改用 io.ReadAll + bytes.NewReader；transform.NewReader 不会报错，失败时返回空字符串，建议加错误检查。
filepath.Walk 遍历含中文目录名时卡死或跳过
根本原因不是编码问题，而是 filepath.Walk 在遇到无法访问的路径（如权限不足、符号链接循环、或 NTFS 的“重解析点”）时默认 panic 或静默跳过。中文名只是让这类路径更容易被误判为非法。
- 务必提供自定义的
filepath.WalkFunc，捕获并处理error参数，不要忽略它 - 某些杀毒软件会在中文目录下注入不可见的虚拟文件（如
~$xxx.docx），导致os.Stat失败，Walk默认行为是终止遍历 - 如果路径含
\uFFFD（Unicode 替换字符），说明上游解码已出错，此时再走Walk会触发无效路径操作
示例安全写法：
filepath.Walk("中文目录", func(path string, info os.FileInfo, err error) error {
if err != nil {
log.Printf("skip %s: %v", path, err)
return nil // 继续遍历，而非 return err
}
fmt.Println(path) // path 此时已是合法 UTF-8 字符串
return nil
})
跨平台处理中文路径时最易忽略的点
Linux/macOS 默认 UTF-8 环境，Windows 默认非 UTF-8 环境——但 Go 二进制本身不感知系统 locale，所有路径操作都依赖你传入的字符串是否为有效 UTF-8。
-
os.MkdirAll("用户目录/中文子目录", 0755)在 Windows 上若源码非 UTF-8，生成的目录名就是乱码，后续os.Open找不到 - HTTP 文件上传中，
multipart.FileHeader.Filename是客户端发送的原始字节，Chrome 发 UTF-8，IE 可能发 GBK，必须按Content-Disposition的filename*参数解析（RFC 5987），不能直接信任Filename - 用
exec.Command调外部程序（如ffmpeg）处理中文路径时，子进程继承的是当前进程的环境编码，Windows 上需确保传给它的参数是 GBK 字节（用syscall.UTF16FromString或第三方库如go-win64api）
真正麻烦的从来不是“Go 怎么处理中文”，而是你没意识到：字符串从哪来、以什么编码进来、目标 API 期望什么编码——中间任何一个环节断链，中文就变成问号或方块。
