写了一个http服务器 workermanhttpd，不知道有什么问题
其实已经写了很久，但没在生产环境用过。也没宣传过。
https://github.com/dvaknheo/workermanhttpd
https://gitee.com/dvaknheo/workermanhttpd
写的时候参照 webman 精简的。
开始还想和协程方式那样处理折腾一些问题，后来没管了
再后来配合我的 duckphp 框架 实现 fpm/ workerman 两栖。
对 workerman 了解不深，不知道会有什么问题。
workerman 也是和 php-fpm 一样多子进程的吧。
如果是用协程模式，wokermanhttpd 的协程安全会有问题。
其他地方就没底了
1104 2 0
2个回答
相似问题
年代过于久远，无法发表回答
暂时没有细致看代码，但要说问题，可能就是这个东西有没有实际意义了；
一般情况从fpm切换到cli下面无非是想使用常驻或者一些多线程的一些便利，在一些工程处理上肯定是做搬迁；举个例子，比如之前开发的是TP框架，我现在想切换到cli下面使用不管是Workerman还是reactPHP还是swoole，肯定优先考虑的是业务代码变动不要太大的切入到这套体系里；cli->fpm反之亦然。
没有哪个用户会因为两栖而选择一个框架，是没有市场的，如果是一个易移植的框架可能会非常吃香。
那么，看来就和 webman 类似的了。WorkermanHttpd 并不是个框架，而是 http 服务器。
兼容直接调用 public 目录下直接使用 .php 文件的功能。
直接 echo 输出，不用非得在 Response 对象里操作。
header() 之类的不兼容函数，只需要在前面加个
改由 WorkermanHttpd::header() 就可以了，参数也一样。
其实要在webman上面实现和fpm其实也不是很难，写两个入口，甚至利用start.php作为fpm的入口也可以，只需稍稍改造以下即可；
判断是否是cli模式，如果不是，就走fpm那一套，利用composer autoload加载框架对应的内容执行并返回，如果是cli并且有workerman常量，那么就走webman相关的逻辑，关于http服务器，其实对于webman来说只是其中的一个进程而已。
当然，如果不想这么暴力，想要用工程化的思路解决这个地方的这个问题的话，可以使用适配器模式处理，就好比数据库的各种驱动，mysql驱动、odbc驱动、pgsql驱动等