Sukka 写前端、网络和基础设施时，习惯先把边界和代价摊开。把「Travis CI 使用 Windows 环境时换行符自动转换为 CRLF 的解决方案 | Sukka's Blog」整理成可落地的中文笔记：问题在哪、默认做法会踩什么坑、该怎么选。原站导航和广告已去掉。

TL; DR：

修改 .travis.yml 中 OS 的设置后进行测试，Travis CI 上 Linux 的 Build 正常、但是 WIndows 的 Build 全部都 Fail 了：ESLint 报错 error Expected linebreaks to be 'LF' but found 'CRLF' linebreak-style 。

问题很简单，看日志就知道了：行尾的换行符转换问题。CRLF 和 LF 都是什么已经没必要再冗笔解释了。 写了可能有助于这篇文章的 SEO，但是没啥必要，我的博客在 Google 的权重已经足够高了 。

缘起

几乎所有 Experienced Git Users 都会选择后面两个选项（绝大部分项目的代码规范都要求使用 LF 换行符、Windows 上大部分 IDE 也都支持 LF 换行符，没理由不用）， 第一种选项可能是为了照顾使用记事本开发的用户 ， 但是 Git for Windows 安装时选项默认选中第一种 。Travis 在初始化 Windows 构建时，目前也是采用的第一种且不可更改（环境初始化不可控）。

知道了 Git for Windows 的这个行为以后，就很容易解释问题是怎么出现的了：虽然 Repo 中所有文件都使用 LF 换行符，但是在 git clone 时被全部转换为了 CRLF 换行符，导致 ESLint 无法通过。

分析

解决的方案有两种，一种是编写 shell 将本地所有文件的 CRLF 换行符替换为 LF 换行符，另一种方法是「解铃还须系铃人」、用 Git 解决：

在 Travis CI 中，还可以限制只在 Windows 上的 Build 重整换行符，可以根据 Travis 提供的环境变量 $TRAVIS_OS_NAME 判断当成操作系统。所以最后只需要在 .travis.yml 中添加下述 shell 步骤即可：

解决

– if [ [ $TRAVIS_OS_NAME == "windows" ] ] ; then git config core.autocrlf false && git add – – renormalize . && git reset – – hard; fi 参考 hexo-filter-nofollow 的 PR #5 。

值得单独记下的点

• Checkout as-is, commit UNIX-style line endings – 在 checkout 时跟随来源文件的换行符，但是 commit 时使用 LF 换行符（本地文件的换行符不改动）
• Checkout as-is, commit as-is – 不论 checkout 还是 commit 时都保留原始的换行符
• 首先禁用 Git 配置中的换行符自动转换，直接使用 git config core.autocrlf false 即可
• 使用 git add –renormalize . ， 根据 core.autocrlfgit 重整所有换行符
• 使用 git reset –hard 回到 HEAD

落地时建议先做的 5 件事

1. 用自己的流量和设备测，不要只抄厂商推荐最小配置。
2. DNS、CDN、代理分流先画清 Fake IP 和 Real IP 的边界。
3. 前端性能看 CLS、白屏和重复渲染，而不是只看打包体积。
4. 基础设施变更走 Git，能复现、能回滚。
5. 结论写成可检查的清单：接口、超时、失败样本、回滚版本。

和智能体产品怎么接

龙虾PRO做 OpenClaw 落地时，网络、DNS 和前端性能笔记最有用的是「边界」：哪一层该加速、哪一层不该假装智能。数字员工调用外部能力前，先把超时和失败路径写死。

本文侧重全链路风控方法论。落地时请用自身业务单据做回放验证，不要把示例阈值直接当生产策略。 相关：风控体检 · 方案资源