10.4 跨平台协作问题
Tip
看不见的字符，往往是最致命的杀手。
1. 为什么要学这个?
你在 Windows 上写了一个自动部署脚本 deploy.sh。
本地运行一切正常。
你把它推送到 Linux 服务器上运行。
报错：bash: ./deploy.sh: /bin/bash^M: bad interpreter: No such file or directory
你甚至根本看不出代码哪里错了。
凶手是不可见的换行符。Windows 和 Mac/Linux 对"换行"这件事有着跨越半个世纪的误解。
2. 核心概念：CRLF vs LF
打字机的遗产
计算机早期的设计模仿了打字机：
- CR (Carriage Return, \r): 将打印头移回行首（回车）。
- LF (Line Feed, \n): 将纸张往上卷一行（换行）。
- Windows: 坚持复古，用
CRLF(\r\n) 代表换行。 - Mac/Linux: 觉得浪费空间，只用
LF(\n) 代表换行。
冲突点：如果不加干涉，Windows 用户提交的代码全是 CRLF，Mac 用户拉下来就会乱码或报错。
3. 解决方案 (HOW)
我们无法改变操作系统，但我们可以强制 Git 遵守规矩。
最佳实践：在项目根目录新建一个 .gitattributes 文件。
这个文件告诉 Git："不管你在哪个系统上写代码，提交到仓库时，必须把换行符统一转成 LF。"
1. 创建 .gitattributes
在项目根目录下新建文件 .gitattributes，写入：
# 强制所有文本文件在仓库里存为 LF
* text=auto eol=lf
这一行配置，胜过一万句口头约定。
2. 统一文件名大小写
- Windows:
Login.tsx和login.tsx是同一个文件。 - Linux: 它们是两个完全不同的文件。
避坑：
- 全小写 (kebab-case): 文件名一律用小写，如
user-profile.tsx。 - Git 敏感设置:
git config core.ignorecase false。
4. 真实案例
Story
那个瘫痪的 Shell 脚本
某公司的运维工程师在 Windows 电脑上编写了一个数据库备份脚本 backup.sh。
他推送到 GitLab。
晚上 12 点，Linux 服务器定时任务执行该脚本——失败。
报错提示 command not found，但命令明明是对的。
原因：
脚本变成了 backup.sh\r。Linux 试图去寻找一个叫 bash\r 的解释器，当然找不到。
是那个看不见的 \r (CR) 毁了一切。
Vibe 心法：
真正的跨平台协作，不是让每个人都用 Mac，而是建立一套无视平台差异的规则。
.gitattributes 就是这套规则的法律文本。
5. 本章小结
- 标准化：仓库里只存 LF。
- 自动化：用
.gitattributes自动转换，别依赖开发者自觉。 - 敏感性：永远假设文件名是区分大小写的（因为生产环境 Linux 区分）。