把 PHP 内置服务器跑在 9000 端口，命令就一行：php -S localhost:9000。敲下去，终端立刻回一句 PHP 8.x Development Server started，然后光标卡在那儿不动了。它不会自己退出，也不会给你什么花哨的界面，就是一个最原始的 HTTP 服务，等着接请求。

我最早用这玩意儿是图省事。本地调个接口，不想开 Apache，不想配 Nginx，更不想动 Docker。一个 PHP 文件，扔到目录里，php -S localhost:9000，浏览器打开 http://localhost:9000，完事。但用多了才发现，这东西的脾气比想象中怪。

先说端口本身。9000 在 PHP 圈子里其实有点尴尬——它太容易被别的服务占了。Xdebug 默认监听 9000，php-fpm 也常用 9000，你要是同时开了 Xdebug 和内置服务器，十有八九会撞车。报错信息还特别含糊，就一句 Failed to listen on localhost:9000，不告诉你是谁抢的。我第一次遇到时折腾了半小时，最后 lsof -i :9000 才发现是 Xdebug 在后台挂着。所以现在我用内置服务器，端口一般随手改成 8000 或者 8080，避开那个雷区。

但 9000 也不是不能用。关键在于你清楚自己在干什么。比如做微信支付回调调试，微信那边只允许 80 或 443，本地没法直接映射，就得靠内网穿透工具把外部请求转到本地某个端口。这时候 9000 反而好记，跟 php-fpm 的默认端口一致，脑子不用切换。我有个同事专门用 9000 跑内置服务器，理由是“看见 9000 就知道是 PHP 的东西”，算是一种肌肉记忆。

内置服务器的路由规则也值得说。它默认会把请求映射到当前目录下的文件，找不到就返回 404。但如果你给了一个不存在的路径，比如 /api/user/1，它不会自动去找 index.php，除非你显式指定路由脚本：php -S localhost:9000 router.php。这个 router.php 里你得自己写逻辑，判断请求路径，决定加载哪个文件。很多人第一次用内置服务器做 REST 接口，发现 /users/1 死活 404，就是栽在这儿。它不是 Apache 的 mod_rewrite，没有 .htaccess 那套东西，一切靠 PHP 代码自己兜。

性能方面别抱幻想。内置服务器是单进程的，一次只能处理一个请求。你开两个浏览器标签同时请求，第二个就得排队。我试过用 ab 压测，并发 10 个请求，响应时间直接飙到秒级。所以它只适合开发调试，上线绝对不行。有人拿它跑本地 Webhook 接收，结果第三方平台重试了好几次，因为第一个请求还没处理完，后面的全堵着。这种坑踩过一次就记住了。

还有个细节：内置服务器默认不处理静态文件的缓存头。每次刷新，CSS 和 JS 都是重新拉取。开发时无所谓，但如果你在调前端性能，可能会被误导。我一般会在 router.php 里手动加 header('Cache-Control: no-store')，省得浏览器缓存捣乱。

最后说个实际场景。上周帮人排查一个上传接口的问题，代码在 Nginx 下正常，换到内置服务器就报 POST Content-Length exceeds the limit。查了半天，发现是 PHP 内置服务器对 post_max_size 的处理跟 Nginx 不一样——它会在读取请求体之前就检查 Content-Length，超了直接 413，根本不给你在 PHP 里改 ini_set 的机会。解决办法要么调大 php.ini 里的 post_max_size，要么换端口换环境。这种差异，文档里写得含含糊糊，只有真撞上了才明白。

9000 端口本身没什么特别，特别的是你用它来做什么。内置服务器是个趁手的临时工具，但别把它当正式环境使。知道它的边界在哪，比记住那行启动命令重要得多。