楼上正解，注意修改 TG 的路径为自己电脑上的实际路径

这不算啥，很多用得不频繁的 QQ 小号还强制要你刷脸验证呢？

有 review 总比没有 review 好，有的小公司代码直接都没有 review 环节的。

我编辑了一个较长的帖子，但是发不出来，被吞帖了，IP 还被禁了，我临时换了一个 IP ，还好找回了编辑的内容，所以把内容发在图片上回应诸位，不知道能不能发出来，其中的观点你们不管赞同与否，这是我最后一次回复此问题了，谢谢大家。

@void1900
@liuxu
@rekulas
----
图片中提到的链接：
https://www.baeldung.com/linux/file-mime-types

---

https://i.imgur.com/YT39yXO.png

@InternetExplorer 再补充一点，如果你是在命令行直接调用 php 文件（比如 php hello.php, php hello2.123 <---后缀名不相关，可以任意），那这种情况就跟 MIME Type 没有关系，他就是直接读取源码然后解析<?php ?>包含的代码，只要你把 PHP 文件放到任意的 Web Server 里边，要通过 HTTP/HTTPS 访问，那 MIME Type 就是绕不过去的了，别管你看没看到 Content-Type ，看到的 Content-Type 是啥，Web 服务器在发送结果之前，都按自己内部定义的或者默认的 MIME Type 进行了分析和处理。

@InternetExplorer 是的，你这个表述大部分是对的，但对于 MIME Type 的理解还是限制在了 Content-Type 上，这也不算冷知识了，大家都知道， 早期 PHP 源文件为了区分不同的版本，甚至还使用.php4 和.php5 这样的后缀名呢，这都不影响，MIME-Type 用来指代和归类一类文件，比如 .php4 .php5 .php 都可以统一归为一种 MIME Type ，至于叫什么名字无所谓，你甚至可以把它叫做 application/my-php-file, xxx/xxx 这样的名字也只是一种约定速成的形式。为了 HTTP 统一接口，统一调用而已。

PHP 本身跟 mime 没关系，但是服务器软件要解析和处理 PHP ，就少不了 MIME Type 的掺和了。

不管是什么 Web 服务器（ Apache ，Nginx ，IIS 等）在以文件后缀名作为区别对请求进行分流的时候，Web 服务器内部就已经是通过不同的文件类型来分别做不同的处理了。多个不同的后缀名文件也可以设置归到一个 MIME Type 下，用一种方式统一处理（比如上面举的例子，多个不同的 php 文件的后缀名实质都是 PHP ）。然后，已知的图片类型加图片类型的 Content-type ，文本类型加 text 这一类的头部，经过动态解析的页面，统一都使用 text/html ，接口调用的根据需要显示 json 头部或者 xml 的头部标识。

要注意一点，浏览器的 Content-Type 只是 MIME Type 的应用之一，而不是全部。MIME Type 的存在让 HTTP 类应用各种文件类型前后呼应，功不可没。C/S 架构，B/S 架构少了任何一端配合都不行。

@eason1874 又来一个在这杠，我再强调一次，MIME Type 的应用很广泛，客户端和服务端都有，不是你在浏览器看到的那个 Content-Type 才叫 MIME Type ，你在配置转发的时候，已经认定 PHP 这个类型的 MIME 包括的这一类文件需要后端解析了，居然都解析过了，自然看不到原始数据了。一群人狭隘地认为浏览器里面那个“Content-Type”才叫 MIME Type

突然想起来一个老梗：
如何让一群程序员马上争论起来？
——“PHP 是世界上最好的语言”

-------------

万万没想到，有一天我也变成了这种人，终究还是没躲过。


散了，我克制一点。干正事要紧。

@miencun 又来一个搞笑的。你的两个观点都大错特错。你甚至还不如他 @void1900
引用你的话：
“扩展名和 Mime 毛关系都没有，你以为 php 叫 application/x-httpd-php ，谁定义的？浏览器为什么会暴源码，因为浏览器不认识 application/x-httpd-php ”
----
解答：
1 、扩展名和 Mime 是一一对应的关系，当然了，也可以一对多，一个 MIME 对应多个拓展名。
2 、浏览器暴露源码是因为 Web 服务器处理失误输出了源文件的原始数据（ RAW DATA ），跟你浏览器收到什么 Content-type 没有关系，这个东西很好证明，你可以不用浏览器啊，Linux 有现成的 curl 命令，Web 服务器端配置有问题的话，你用 curl http://xxx 不一样能得到服务器返回的源码吗？跟 Content-Type 有什么关系呢？只跟你服务器输出了什么东西有关系，不止是 Content-Type ，绝大多数的 HTTP 头部信息其实都是可以忽略的，不影响结果输出，绝大部分的头部信息都属于冗余信息，需要用到的时候才拿出来用。

@void1900 对牛弹琴，说了那么多白说了。如果你要好好说话，你可以说 MIME Type 不能和拓展名相关联，只能做描述文件类型用，那这个问题本身就有争议，我可以考虑接受。尽管这个问题有争议，回复了那么多，你也应该知道我要说的 MIME Type 就是 Web Server 根据不同拓展名来处理不同类型文件的意思。而不是杠子眼，为什么我说有争议，是因为这个问题你在 Google 和 Stackoverflow 上都有两个版本，普遍认为 Apache ，IIS 这样的关联比较强（直接写在配置文件里或者配置界面上），Nginx 等代理性质的服务器关联比较弱，但不是代表没关系。

第二个，关于你说的 SetHandle ，那你觉得 Apache 是凭什么东西找到它要 Handle 的对象的呢？

@void1900 语文不好的是你，理解能力差，所以一开始才看不懂别人的回复里面已经约定了很多东西，你视而不见，需要一遍又一遍跟你解释，我说了不急，只要 V2 这站还活着，让时间给你答案。

@miencun CGI 你也得用相应的规则配置去匹配.php 这一类后缀的文件，这还叫没关系。虽然 MIME Type 不全等于文件拓展名（这一点我上面的回复说了，就算我强行关联吧），但 MIME Type 就是为了让 HTTP 服务 C/S 两端前后呼应，用来区分不同文件类型的，想想你用 Niginx 配置代理 PHP 时候怎么写的 location 来匹配呢，用了 php 的拓展名没有？

忘记艾特你了，请看上一楼，专门回复你的。 @void1900

你是不是傻，来，我来一一回复你：

“人家结尾都说了 “并没有在内部 mime 列表中查出一个['php'=>'type/php']这种东西。”。”

——请把我这个帖子的回复连贯起来看，我上面的回复里面说了，并不是要明示“'php'=>'type/php'”这样的东西才叫 php 有 MIME Type ，没定义不代表就没有，MIME Type 是 HTTP 类应用在区分不同文件类型的时候引入的概念，但不是说这类东西只能跟浏览器挂钩，Web 服务也是需要的，比如 Apache 里面是定义了 PHP 的 MIME Type 类型是 application/x-httpd-php ，你可以不加这个名字，叫 application/x-abc 也行，总之是为了区分不同类型的文件； Nginx 默认只定义了所有常见的静态资源类型的 MIME Type ，没去定义任何的动态类语言的 MIME Type （ php ，jsp 等等），是因为 Nginx 常用做前端负载均衡代理服务使用，你要给他一个 PHP 的 MIME 定义，他也没错，Nginx 对不同的文件类型，也同样有自己 MIME Type 概念，其实严格一点说，所有具有后缀名的文件都有 MIME Type ，只要我们需要了，我们就可以给这一类文件定义一个 MIME Type ，Web Server 靠这个东西区分不同的文件类型该做什么样处理。你的问题在于陷入了一个误区，认为只有浏览器的 Content-Type 跟 MIME Type 有关系，其他的地方都没关系。

---

“写正则用的是扩展名，那假如我将整个目录都 proxy_pass 给 fpm 呢？你还怎么扯你的扩展名？”

——你当然可以这样设置，但你这是正常和常规的做法吗？万一你这个路径下边有子目录呢，子目录里面有图片，js
，css 文件呢，你是不是要不管三七二十一统统交给后端去解析，还是说你把所有的子目录一个个分开来设置，不管嵌套几层，统统分开设置，反正就是打死不用后缀名来匹配。顺便建议你，平时在服务器上配置 Nginx 和 PHP 也采用你说的做法，打死不要用 php 后缀名来做正则匹配哦，我会为你鼓掌，你要偷偷用了你就是小狗。

@void1900 还有指明一点，别人的回答你都不仔细看，甚至没弄明白别人说的是什么就率先站出来反对，你看看我在这个帖子下的所有的回复，哪一个兄弟的回复的答案我没看？并且是有人给出自己观点，我都会对照自己的表述一一回应，错了就错了，概念错误，还是逻辑错误，又或者是意思没表达清楚，我都大方承认，就你光在这自说自话，压根不管别人说的是啥，这是一个学习者该有的态度吗？
-----
顺便说一句，V2 发帖的好处是无法删帖无法修改，究竟打了谁的脸，就留给观众老爷们评判吧，让时间说话。

@void1900 你就继续掩耳盗铃吧。你再好好读读楼上那位兄弟的回答，假如你能理解的话。要是读不懂，那我就送你三个字：“你赢了！”，散会

@liuxu 另外说一下，关于第二个问题，Nginx 使用 location 配置 php 时，实际上已经在正则表达式里边传递 php 的后缀名了，所以说成是后缀名匹配也无大的错误。

@liuxu 你的这个回答恰恰说明了 php 会不会暴露源码跟 MIME Type 高度相关，而不是不相关，打了不少人的脸，@void1900 首当其冲，脸都被打肿了。先不讨论你回答的正确性（因为我懒得验证），根据你的回答，我阐述有问题的地方仅有两个：
一. 不是所有的 Web 服务器默认 MIME Type 都是 application/octet-stream ；
二。不能把 Nginx 通过 location 配置 PHP 解析的方式统一叫成后缀名或 MIME Type 识别，它可能仅仅就是一个 URL 路径的正则匹配。

----
当然，现在的我仍然坚持后缀名≈MIME Type 的观点，我不是说他们概念和定义相等，是说他们对 Web 服务器的影响差不多，前后端搭配，不仅是浏览器需要 Content-Type ，Web 服务器本身也需要区分哪些文件需要处理，哪些文件是直接输出。

你说的“但是从 nginx 的角度来看，它就是一个正则字符串，并没有在内部 mime 列表中查出一个['php'=>'type/php']这种东西。”这个问题我上面的回复说过了，不需要输出给浏览器特殊标头（ Content-Type ）的文件，并不需要显式定义，因为不管是 php ，还是 jsp 他们最终呈现给浏览器都是 text/html 而已，但不意味着在 Web 服务器内部没有一个标识来把这些 php 文件统一归类，有可能这个东西不能叫 MIME Type （你可以叫 proxy file group1 ，proxy file group2 或其他），但绝对存在这样一个标识，Nginx 这样的代理服务器也不例外。

综上，结论就是 PHP 爆不爆源码还真的跟 MIME Type 有关系。别吵了。

@void1900 很好，结贴