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 的时区设置完全独立。
CRMEB打通版是一款全开源支持免费商用的PHP 多语言商城系统；CRMEB技术团队历经6年时间匠心之作！系统采用前后端分离技术，基于TP6+Uni-app框架开发；客户移动端采用uni-app开发，管理后台前端使用iviewUI开发。系统支持微信公众号端、微信小程序端、H5端、PC端多端账号同步，可快速打包生成APP；赋能开发者，减少重复造轮子；系统支持自动检查安装环境一键安装部署，使用简单方便
立即学习“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')) 一层层确认。