17370845950

PHP 仍适用于CMS、内网后台等场景，而非高并发微服务；$_POST为空多因Content-Type不匹配，如application/json需用php://input读取；mysqli专用于MySQL，PDO支持多数据库；时区问题源于date.timezone配置而非系统时间；环境配置如Nginx限

制、OPcache等影响实际运行。

PHP 作为后端语言依然可用，但是否“适合”取决于具体场景——它不是过时了，而是被误用了：拿它硬扛高并发微服务、替代 Go/Java 做长连接网关、或当 Node.js 用去写大量异步 I/O，大概率会踩坑；而做 CMS、企业内网管理后台、中小流量 Web API、WordPress 插件或快速原型，它仍然高效、低门槛、生态成熟。

为什么 $_POST 为空但前端明明发了数据？

常见于 Content-Type 不匹配。PHP 默认只解析 application/x-www-form-urlencoded 和 multipart/form-data 两类请求体，自动填充 $_POST；若前端用 fetch 发 application/json，$_POST 必然为空。

• 检查请求头：Content-Type: application/json → 改用 json_decode(file_get_contents('php://input'), true) 读原始体
• 表单提交或 FormData → 确保没手动覆盖 Content-Type，浏览器会自动设为 multipart/form-data
• Nginx 配置里有 client_max_body_size 限制？超限会导致整个请求体被丢弃，$_POST 和 php://input 都为空

mysqli 和 PDO 选哪个？

不是语法偏好问题，是抽象层级与扩展性差异。mysqli 是 MySQL 专用接口，支持面向对象和过程式调用；PDO 是数据库抽象层，统一接口但功能受限（如不支持 MySQL 的多语句执行、部分存储过程特性）。

• 项目只用 MySQL，且需用到 mysqli_multi_query() 或 mysqli::get_client_info() 等原生能力 → 选 mysqli
• 未来可能换 DB（如从 MySQL 迁到 PostgreSQL），或团队习惯 ORM（如 Laravel Eloquent 底层依赖 PDO）→ 优先 PDO
• 注意：PDO::prepare() 默认不启用模拟预处理（PDO::ATTR_EMULATE_PREPARES = true），MySQL 5.7+ 下某些复杂 SQL 会被绕过服务端预编译，失去防注入保障

为什么本地 date('Y-m-d') 正确，线上却差 8 小时？

PHP 的时区不是靠系统时间决定的，而是由 date.timezone 配置项控制。Linux 系统时区（/etc/timezone）和 PHP 的时区设置完全独立。

• 查当前生效值：echo date_default_timezone_get();，别只看 phpinfo() 里的配置文件路径
• 在 php.ini 中设 date.timezone = "Asia/Shanghai"，比在代码里每次调 date_default_timezone_set() 更可靠
• 容器部署时注意：Alpine 镜像默认无时区数据，即使 date.timezone 设对了，strtotime('tomorrow') 仍可能出错，需安装 tzdata 包

PHP 后端真正的复杂点不在语法，而在环境链路：Nginx 的 fastcgi_pass 转发是否超时、OPcache 是否启用了 opcache.validate_timestamps = 0 导致改完代码不生效、upload_max_filesize 和 post_max_size 的大小关系是否合理……这些细节不写进日志，就只能靠 var_dump(ini_get('xxx')) 一层层确认。