thinkphp3.2 接收不到 post 参数是因为默认仅依赖 $_post，而其填充受 content-type 限制；若前端发 application/json，需改用 php://input 手动解析；同时需检查 nginx、php 配置及避免重复读取原始流。
ThinkPHP3.2 接收不到 POST 参数，不是框架“坏了”，而是请求格式、服务端配置或调用方式不匹配导致的。核心在于：TP3.2 默认只从 $_POST 读取数据，而 $_POST 仅在特定 Content-Type 下才被 PHP 自动填充。
检查前端发送的 Content-Type 是否匹配
这是最常见原因。微信小程序、axios、fetch 等默认发的是 application/json，但 PHP 不会把 JSON 自动塞进 $_POST —— TP3.2 的 I('post.xxx') 或 $_POST 都为空。
- 若你控制前端，把请求头改成：
Content-Type: application/x-www-form-urlencoded;charset=utf-8 - 这样 PHP 才会解析 body 并填入
$_POST，TP3.2 就能正常用I('post.name')取值 - 若无法改前端（如第三方小程序强制发 JSON），就别依赖
$_POST，改用原始流读取
后端改用 php://input 手动解析 JSON
当 Content-Type 是 application/json 时，必须跳过 $_POST，直接读原始请求体：
- 在控制器方法里写：
$raw = file_get_contents("php://input"); - 再解码：
$data = json_decode($raw, true); - 之后就能取值，比如：
$uid = $data['user_id']; $name = $data['store_name']; - 注意：
php://input不能用于multipart/form-data（如带文件上传），此时仍需用$_POST+$_FILES
确认服务器和 PHP 配置没拦住 POST
即使前端发对了，中间层也可能静默丢数据：
- 检查 Nginx 的
client_max_body_size（默认常为 1M），传大文本或 Base64 图片容易触发 413 错误 - 查 PHP 的
post_max_size和max_input_vars：前者太小会截断整个 body，后者太小（如设为 100）会导致字段超量被丢弃，且无提示 - 确保
variables_order包含P（即EGPCS），否则$_POST根本不会初始化 - Apache 用户留意
mod_security规则，有时会拦截含特殊字符的 POST
避免在入口或中间件里误操作
TP3.2 没有现代中间件机制，但有人会在 index.php 或公共函数里提前处理请求，容易出问题：
- 不要在读取前调用
file_get_contents("php://input")多次——它只能读一次，第二次返回空 - 不要手动
parse_str()或json_decode()后又试图用I()，会造成重复解析或覆盖 - 确认没有开启
always_populate_raw_post_data（PHP 5.6+ 已废弃），它可能干扰原始流读取
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
