操作系统兼容测试：三大系统的“性格”差异
做兼容测试这些年，我最大的一个体会就是——操作系统之间的差异，比你想的还要细。
Windows、macOS、Linux 虽然都是“桌面系统”，但它们在文件系统、权限模型、字体渲染、路径分隔符这些底层细节上，几乎全是反着来的。你写个简单的日志输出，在 Windows 上跑得好好的，换到 macOS 就报权限错误，再换到 Linux 连文件路径都找不到。
为什么会这样？说白了，每个系统都有自己的“脾气”。测试的时候，你没法绕过它们。下面我把常见的问题分类梳理一下，都是我踩过的坑。
核心原则：永远不要在单一系统上做完整验证。你至少需要一个 Windows、一个 macOS 和一个 Linux 环境。我自己习惯用虚拟机 + Docker 混搭，覆盖尽量多的版本。
字体兼容：同名字体不同长相
字体问题看起来不大，但一出问题就很明显——界面错位、文字变成方块，用户第一眼就觉得你的软件很糙。
我记得有一次，产品在 Windows 上测试时所有中文字都正常，但用户反馈说在 macOS 上“某些按钮显示不全”。我一查，原来是代码里写了 font-family: "Microsoft YaHei", "Helvetica Neue", sans-serif;，macOS 上没有微软雅黑，它 fallback 到 Helvetica Neue 后英文字宽变了，按钮宽度不够。
所以记住这条：
- Windows：自带微软雅黑、宋体、Consolas、Courier New。
- macOS：自带苹果苹方（PingFang）、Helvetica Neue、Monaco。
- Linux：通常是 Noto 系列、文泉驿、DejaVu 等。
怎么做？我建议在 CSS / 代码中写多组 fallback，并且一定在末尾加上通用字体族（sans-serif, serif, monospace）。更保险的做法是把项目中用到的中文字体子集化，内嵌进资源包里。但这个方案会增加包体积，你要权衡。
避坑指南：我曾经遇到过 Linux 上某个字体文件实际字体名和文件名不一致的情况。用 fc-list :lang=zh 先查一遍系统实际注册的字体名，再往 CSS 里写。别直接写文件名，系统不认。
路径兼容：斜杠方向与大小写敏感
这个坑，几乎所有跨平台开发者都掉进去过。
| 对比项 | Windows | macOS | Linux |
|---|---|---|---|
| 路径分隔符 | \（反斜杠） | /（正斜杠） | /（正斜杠） |
| 大小写敏感 | 不敏感 | 默认不敏感（可开启） | 敏感 |
| 根目录 | C:\ 或 D:\ | / | / |
| 用户目录 | C:\Users\用户名 | /Users/用户名 | /home/用户名 |
核心原则：代码里永远用正斜杠 /。Python 的 os.path.join() 或 C# 的 Path.Combine() 会自动处理，但如果你用字符串拼接，八成会出事。另外，Linux 上 config.ini 和 Config.ini 是两个文件，Windows 上却是同一个。我在项目中写过这样的 bug：测试用例在 Windows 上通过了，但 Linux 上因为某个资源文件名大小写不一致导致加载失败。
权限兼容：读写执行三态各不同
权限问题更像一个“暗雷”——不触发你都不知道系统有多严格。Windows 用 ACL（访问控制列表），macOS 和 Linux 用 POSIX 权限（rwx 三组）。
- 执行权限：Windows 靠扩展名（.exe, .bat）识别可执行文件；Linux 靠
chmod +x。如果你把编译后的二进制文件直接从 Windows 拷贝到 Linux，它可能没有执行权限，直接报 Permission denied。 - 系统关键目录：Windows 的
Program Files普通用户写不了；macOS 的/Applications要管理员；Linux 的/opt、/usr也受限。 - 临时文件：各平台临时目录不同（
%TEMP%、$TMPDIR、/tmp），而且有些环境临时目录有空间或权限限制。
我个人的做法：在测试框架里加一个“权限验证”步骤，自动尝试写入系统关键目录，如果失败就打印警告，而不是直接 crash。这样能提前暴露问题。
注意：macOS 从 Catalina 开始加入了“强化运行时”和“公证”机制，未签名的应用可能被直接杀掉。Linux 上则要注意诡异的 umask 配置，我遇到过一台服务器默认 umask 077，导致你创建的文件只有自己能看到。
其他常见差异：换行符、编码、信号
这些虽然小，但会污染你的测试结果。
- 换行符：Windows 用
\r\n，macOS 和 Linux 用\n。如果你在 Windows 上编辑了一个 shell 脚本，上传到 Linux 执行时第一行就报bad interpreter，因为\r被当做命令的一部分了。 - 文件编码：Windows 默认 GBK（简体中文版），macOS 和 Linux 默认 UTF-8。老项目里写死在代码里的
"中文"字符串在 Linux 上会乱码。我建议所有跨平台项目强制统一成 UTF-8 with BOM 或 UTF-8 without BOM，并在 CI 里加编码检查。 - 信号与进程管理：Linux 有
SIGTERM/SIGKILL/SIGSTOP，Windows 只有CTRL_C_EVENT/WM_CLOSE。你要是写一个守护进程，必须用两套处理逻辑。
避坑指南：我曾经在跨平台工具里用 pid = os.system("taskkill /F /PID xxx")，结果在 Linux 上直接报错。后来改成 subprocess 统一调用平台原生 kill 命令，才消停。
这图大概把本章的脉络理清了。你看，每个大问题下都有好几个小点，测试不能只测一个方向。
最后说一句：我在做灰度验证的时候，操作系统兼容测试往往是最早开始、最晚结束的。因为很多问题只有在真实用户组合中才会暴露。如果你有条件，建议在灰度前先跑一轮全平台自动化冒烟，能省掉大量返工时间。