mimiphp

@lyxxxh2
我明白了。因为如果是我自己部署，肯定 nginx 是放在服务器，而不是容器。
但大多数提供的 docker 镜像都是打包好了包括 nginx ，语言，数据库全部软件包的镜像。
那当然容器对于服务器来说就需要映射端口。
服务器只有一个 80 端口，当然就需要在服务器再安装一个 nginx 来转发不同端口到不同容器了。

但如果是自己部署，我当然是一个 nginx 直接转发到 php-fpm ，即使存在 3 个不同容器的 php-fpm

需要注意的是 php-fpm 是 php-cgi 的进程管理器，php-cgi 只负责处理.php 文件。
所以静态文件还是需要 nginx 来处理，虽然 swoole 可以独立当作 http 服务器，但还是比 nginx 差远了。

我明白你纠结的问题所在。但第三方提供的镜像就是把 nginx 部署进去的，你也只能这样去用。

@lyxxxh2
我不知道具体你 docker 里面到底要运行什么软件。
但如果有任何动态语言存在实际上都可以监听端口的啊。

然后 nginx 任何一个 docker 里面都不要部署进去，直接部署在系统外层。。然后根据不同域名配置不同的 server ，porxy_pass 指定 127.0.0.1:8081
porxy_pass 指定 127.0.0.1:8082
porxy_pass 指定 127.0.0.1:8083
不就好了么？

@lyxxxh2
fpm 不是一定跟 nginx 才能绑定，其实跟一切能代理的软件都能绑定。。甚至 apache 改一下配置也是可以支持 php-fpm 的。
但为什么要用 nginx ，是因为 nginx 强大的并发性能和静态文件的处理能力。。这一点总是有人去忽略，而去谈代理。。。

还有你说的 nginx 绑定 3 个域名需要 3 个或者 4 个 nginx ，这就是你对 nginx 的工作原理不了解导致的了。

不论是不是 docker 安装的 nginx ，其实都只会映射消耗一个或者两个端口。
比如 80:80,443:443 。
docker 映射出来端口后，后面的域名访问就不会消耗端口了。。。。

因为 nginx 或根据访问的域名自动与 conf 配置文件匹配。。。也就是 server_name 这个参数就是来配置域名的。

你不同的域名，就是走不同的 server 配置，每个不同的 server 配置里面的 server_name 就是$host 这个 nginx 变量记录的
也就是说，访问不同的域名，其实都是走的 80 端口或 443 端口，但进入 nginx 的执行逻辑，就是根据不同的配置文件来读取不同的站点目录的事情了。。。。。


至于你说的 ip+端口，当然每个软件监听同一个端口肯定就会冲突，所以一个 ip 下要多个 web 服务，肯定就要消耗不同的端口了。

但 nginx 却是一个 ip 下消耗一个 80 端口就支持无限个域名绑定了。。。。

@happy32199 webman 是基于 wokerman 的开发框架。wokerman 是纯 php 写的网络框架.你可以理解为
wokerman 是 Composer 第三方类库的扩展代码包。类似的第三方类库太多了。但都是 php 脚本代码的。
而 swoole 是 C 语言开发的，我们在谈 php 的性能，那肯定就是指 C 语言开发的 php 底层和扩展。
这一点来说，swoole 已经算是扩充了 PHP 的性能。但 wokerman 是调度了 PHP 内核自带的 pcntl_fork 子进程。
当然性能上来说区别不大，但思路上完全不一样。wokerman 走的多子进程。
swoole 是 C 语言独立支持的协程。

amphp 就是基于 php8.1 官方 Fiber 协程扩展封装的开发框架。

所以我们在讨论一个语言的问题，不是讨论一个框架的问题。

你可以说 swoole,Fiber,workerman ，但不能说 webman 和 amphp ，他们只是基于前面 3 个之一的开发框架而已

@superares
大哥，我整篇内容报考回答你都可以看一下先。。我就是在反对工程化。当然你非要工程化来控制质量，那当然就是希望强类型开发编译方式了。就如某个回答一样，你为什么不换语言呢？
强类型编译检查都通过不了岂不是一目了然了？

@superares
常量指定类型，这个是 class 封装后的一个性能优化，只能算特例。。

因为常量一旦定义，本身就无法修改。
但其实同样也是一个可选项，也就是自动推导依然存在。
但以前的版本是定义函数时都要求返回值配置类型。。这就太强类型化了。
目前更新来看都是漏洞修复，和扩充内置函数。
至于弱化强类型，需要大版本更新才知道，上面说到的只是我个人判断。

@buxudashi
laravel 也是过度设计了
你这句话我非常认同，包括 wordpress 一样。其实严格来说一个语言是否好用，其实就是提现在 laravel 这样的开发框架，和 wordpress 这样的终端开源产品的使用火热程度。
在 web 开发领域，laravel 确实让很多中小型公司能快速开发属于自己的产品，这已经很优秀了。但。。。恰恰问题也出在 laravel 。由于现在程序开发实际就是很多很多不了解原理的伪程序员加入，laravel 架构如何设计，那大多数使用的程序员就认为 php 就是这样的设计了。

比如国内 php 程序员，其实都应该算 thinkphp 程序员，国外 laravel 程序员就算是 laravel 程序员。。
也可以说就是框架使用者。
但你不得不承认这些开源框架的出现才会让 php 这个语言火得起来。
但一个客观事实就是这些基于框架的程序员还不能理解 php 更新的兴奋点，因为他们接触不到。
甚至很多原生 sql 语句都不会写，但他们也一样开发出程序了，不是吗？

java 也同样一大批 springboot 的框架使用者。

前端也一样很多离开 vue ，根本不会写原生 js 。甚至原生 css 都不会了。

至于终端产品的 wordpress 市场占有率也摆在那里。
所以我们可能是更接触深入一些的 php 程序员，我也有自己的开发框架。
但任何语言不就是工具对吗？能用上快速完成任务，就是很好的。

至于 laravel 为什么这么难用，为什么 wordpress 性能这么低。那如果出现了性能瓶颈，你才会愿意去分析和研究原因。
当然这时就已经出现质疑 php 不行的情况出现了。但你稍微深入了解一下，可能自己开发个框架，或者原生写一下代码，其实 php 或者几个原生 sql 就解决了你的性能问题了。
程序员也是在逐步学习进步中的。

只是真实情况就是 laravel 或者 wordpress 就已经让很多人质疑 php 性能低了。
但另一面来说又让很多人不得不承认 php 实在太方便了，不是吗

@happy32199
因为协程开发本身就需要更高深一些的技术把控，虽然协程是虚拟化的调度，但同样需要去了解 CPU 工作原理。所以官方一直没有做具体的例子，其实提供了 Fiber 你只要理解原理是完全可以操作的了。但如果你不是为了拿 php 做 cli 命令行模式去做纯后端，php 还是更适合走 php-fpm 的 cgi 网页模式。因为在 web 领域，php 的部署方式实在是太方便了。热更新这一点就非常符合 http 的短连接方式。

我上面已经举例，百度，淘宝等等大型互联网公司也会拿 php 来做 web 服务器的后端语言的。

如果你是中小型网站比如我的 https://ffsou.com 同样是非常顺手的。

至于你说的在上海 php 只能拿 8 9k..这完全就是每个公司的技术主管的问题。我们客观一点，你随便去任何一个在线求职网站看看。如果你进入一家以 php 为主体的开发公司，薪资肯定不会这么低的。你非要去一个.net 主体的公司，去问 php 岗位薪资，那当然就低人一等了嘛。。

就类似你去一个 vue 前端的公司，非要谈 react 或者 angular 多优秀。同样会被嗤之以鼻嘛。。。

比如我现在发布 php8.3 更新了，就放在 php 讨论组。。。却还是跑来一些强类型语言的人来找存在感一样的道理。道不同不相为谋而已

@a632079
你回答得蛮好的，也肯定是持反对态度的。但希望你回答时，不要人身攻击，满篇带着不屑的态度。每个人的认知本来是有限的，并且任何语言只是工具。我整篇内容发表的是我个人观点，其中心思想就是 javascript,php,python 都是脚本语言，脚本语言的特性就是不要去让开发方式走强类型的伪编译，打包工程化。而微软和 facebook 却带着全世界的脚本程序员一直走工程化的方式，这是一种改变，但我认为没有任何性能提升。

至于你回复的一直说我认知问题，其实你自己也有很多认知错误。php-fpm 不是解释器，是进程管理器.

我拿 java 的 web 部署举例，是指：一个 web 服务器，任何一个动态语言都能监听端口，如果要谈单一语言的性能，强类型语言来做 web 服务器肯定比脚本语言要高效。但实际部署时为什么用 nginx ，原因就是 nginx 是直接面对用户请求的并发。nginx 的目的并不在 Proxy ,Proxy 只是它必须把逻辑部分转发给其他语言，但 nginx 强大之处在于静态文件的处理，比如图片，视频，html 等等。我回答你就不会去讽刺你的认知，我只是纠正一下。希望你也能做到这样的沟通。

至于后面你还在说协程本身协程本来就是运行时基于线程模型上的进一步抽象罢了。这个‘罢了’用得不够好。多线程一直是物理支持的 CPU 通道调度，程序要求 CPU 调度就会存在性能损耗。协程就如你说的各个语言逐步支持，但协程就是发展方向。脚本语言都在支持协程的路上，也就是中心思想就是协程是抽象化的线程完全正确，但脚本语言在性能上利用协程包括你说的强类型也在利用协程，这才是一个正确的性能优化方向。

也就是强类型和弱类型语言请不要再拿性能来说话，因为协程的出现，本身就已经在提高性能的路上了。