一个小坑提醒:某个 Class 或某个 Trait 突然找不到。

“我 Mac 本地没问题啊!”

“但是为什么 Linux 服务器上报这个错啊???”

[Symfony\Component\Debug\Exception\FatalErrorException] 
Trait "App\Library\XXXX" not found

“太诡异了,这怎么查?”

同事中又有人被这个问题坑了,你可以搜到很多人遇到这样的问题,我先告诉大家如何解决,再解释原因。

如何解决

  1. 查看是否文件名是不是大小写弄错了?
  2. 查看 namespaceclass 的名字的大小写弄错了?

解决方案就这么简单,肯定是遇到了大小写的问题。

为什么 Mac 上没有问题,Linux 上有问题呢?

主要原因是 Mac 上的文件系统 HFS+ 默认是大小写不敏感(case-insensitive)的,当然可以修改为大小写敏感(case-sensitive)。
但是 Linux 系统却默认是大小写敏感的(case-sensitive),所以在 Mac 上能找到的文件,在 Linux 上却找不到。

当然为了了解这个问题,你还需要了解 PSR-4 的 autoload 方式。

为什么不把 Mac 直接格式化为大小写敏感(case-sensitive)?

因为历史的原因,如果你格式化为大小写敏感,很多软件都会有问题,比如大名鼎鼎的 Adobe 家的产品就有问题,刚才同事反馈,idea 家的软件也经常会莫名其妙崩溃(最终他不得不重新格式化为不敏感)。

在 Mac 上,如果发现文件名大小写有问题,怎么办?

你以为直接把文件名修改就可以解决问题了吗?你太年轻了,文件名大小写变化,git 根本没有任何察觉,还是那个原因,因为文件系统 HFS+ 默认是大小写不敏感的(case-insensitive),(谢谢 @NauxLiu 分享)你可以有这样几个选择:

方案一:

  1. 删除旧文件,提交代码。
  2. 添加新文件,提交代码。

方案二:修改配置

git config core.ignorecase false

方案三:

$ git mv test.txt tmp.txt
$ git mv tmp.txt Test.txt
$ git commit -m "Renamed test.txt to Test.txt"

希望对你有帮助。

原文链接:https://www.lijinma.com/blog/2017/02/09/cl...

本作品采用《CC 协议》,转载必须注明作者和本文链接
写文字大部分时候是因为我希望能帮助到你,小部分时候是想做总结或做记录。我的微信是 lijinma,希望和你交朋友。 以下是我的公众账号,会分享我的学习和成长。
本帖由 Summer 于 7年前 加精
lijinma
《L03 构架 API 服务器》
你将学到如 RESTFul 设计风格、PostMan 的使用、OAuth 流程,JWT 概念及使用 和 API 开发相关的进阶知识。
《G01 Go 实战入门》
从零开始带你一步步开发一个 Go 博客项目,让你在最短的时间内学会使用 Go 进行编码。项目结构很大程度上参考了 Laravel。
讨论数量: 43
Summer

所有要使用 Homestead ,坑踩得多了,就知道 homestead 的好了。

7年前 评论
lijinma

@Summer 老大你说的对,嘿嘿

7年前 评论

金马,我想打赏5毛。

7年前 评论
lijinma

@张铁林 欢迎鼓励,铁林,你的每一毛都会成为我努力写好文章的动力。。

7年前 评论

用 Linux 开发就是有这个优势,有时候同事在 mac 上没注意大小写,我代码拉下来就挂掉了

7年前 评论

@lijinma
金马,会不会打我?

file

7年前 评论
lijinma

@qq215672398 哈哈哈哈哈,下次遇到,打他们

7年前 评论
lijinma

@张铁林 已收到,为什么打你。。。我很开心

7年前 评论
lijinma

我明天拼命找总结、反思、写作的意义,有人打赏绝对算一个。

7年前 评论

使用arch 做开发机好多年了,早就养成了严格大小写的习惯

7年前 评论

遇到过...git上处理也挺麻烦的...

7年前 评论
lijinma

@Insua 恩恩,感觉这应该是程序的基本素养,哈哈

7年前 评论
lijinma

@helone 我上面写了。。。。。删除文件提交,然后再添加文件提交。

7年前 评论

@lijinma 现在我是这么处理的,以前第一次遇到启动Git大小写敏感,结果一堆同事死活拉不出代码...

7年前 评论
lijinma

@helone 哈哈,原来有这样的问题

7年前 评论

不需要删除提交,添加提交,直接 git mv 命令就行了。

7年前 评论

或者直接将 git 项目设置为大小写敏感 git config core.ignorecase false

7年前 评论

好像有两个文件相同的命名空间也会报这样的错误

7年前 评论
lijinma

@NauxLiu 又学习了一招,多谢,哈哈

7年前 评论
lijinma

@Hanccc 你指的是?举个例子。

7年前 评论
风吹枫落

这是在win上的日常

7年前 评论

Windows不用Homestead的話,坑更多

雖然Homestead的坑也不少就是了

7年前 评论
lijinma

@风吹枫落
@quericy
谢谢分享,原来如此。

7年前 评论
lijinma

@NauxLiu 我试了一下,兄弟
1) git mv

$ git mv test.txt Test.txt
fatal: destination exists, source=test.txt, destination=Test.txt

我觉得应该合理的做法应该是:

$ git mv test.txt tmp.txt
$ git mv tmp.txt Test.txt
$ git commit -m "Renamed test.txt to Test.txt"

2) git config core.ignorecase false 亲测有效。

7年前 评论

我记得用vagrant 也是大小写不敏感的呀。
因为共享目录还是mac本地的,因为mac不敏感,共享目录也不敏感了。当然docker的挂载目录也是这样的问题。
而且vagrant从1.8.3以后坑好多啊,不知道是vagrant的坑,还是vbox的坑。总之用着不舒服。最后php环境还是装到本地了。还是这样舒服哈哈。

7年前 评论

@lijinma 我的系统是 macOS 10.12.3,直接用 git mv 没有问题,你可以试试 git mv --force file File

7年前 评论
lijinma

@NauxLiu 我知道了,兄弟,git mv 的时候,ignorecase 必须是 true 才可以,如果是 false 报错。

7年前 评论
lijinma

@Boomdawn 我 vagrant 使用起来还好。。哈哈

7年前 评论

@lijinma 我是遇到很多莫名其妙的问题,懒得折腾了。最后一个遇到的就是,弄好环境了打包给同事用。能用的概率很低。。。基本是用不了。 我记得老版本还是好好的。 最后就放弃了。

7年前 评论
lijinma

@Boomdawn 好吧,我之前的公司一直用的 vagrant,新人来了环境很快就搭起来。

7年前 评论
bestony

这么看来,和写代码人的本身规范也有关系。如果Coder的习惯好,这些问题不会出现、

7年前 评论
lijinma

@bestony 你说的对。

7年前 评论

还有有是时候可以试试composer dump 特别是seeder那里没有命名空间 容易找不到

6年前 评论

@lijinma 建议写成全局敏感:

git config --global core.ignorecase false
6年前 评论

我们公司的项目使用homestead就很慢,差不多每个请求比实体机要慢2秒,最后不得不放弃

6年前 评论
Destiny

lala

6年前 评论

碰到过多次这样的坑

6年前 评论
chongyi

@j511002 调试开发还好吧

6年前 评论

git mv test.txt tmp.txt 直接mv test.txt tmp.txt 不行是吧

6年前 评论
lijinma

@mingyun 恩,不行的。

6年前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!