CI 3.x 用 $this->input->post() 安全取 POST 数据，CI 4.x 改用 $this->request->getPost()；二者均自动过滤、trim、防注入，且返回 null 而非空字符串或 false，判空应为 !== null；不可混用 getPost() 与 getJSON()，亦不可在方法签名中硬塞 POST 参数。
直接用 $this->input->post() 最稳妥
CI 3.x 和 4.x 都支持这个方法，它比直接读 $_POST 多一层过滤和类型安全。默认开启 XSS 过滤（可关），自动 trim 空格，还能防空值注入。如果你只取一个字段，比如用户名：$username = $this->input->post('username');，返回的是字符串或 null（不是 false 或空字符串），后续判断更干净。
常见错误现象：有人写 if ($_POST['username'])，但当用户提交空字符串或 "0" 时会误判为 false；而 $this->input->post('username') !== null 才是正确判据。
- 不传参时返回整个 POST 数组（带过滤）
- 加第二个参数
true可关闭 XSS 过滤：$this->input->post('desc', true) - CI 4 中已迁移到
$this->request->getPost()，行为一致但命名更明确
CI 4 必须用 $this->request->getPost() 替代 Input 类
CI 4 彻底移除了 $this->input，所有请求数据统一由 $this->request 对象管理。POST 数据不再混在全局 input 流里，而是按 Content-Type 分离处理。
使用场景：表单提交是 application/x-www-form-urlencoded（最常见），就用 getPost()；如果是 JSON 请求体，得用 getJSON()，不能混用。
-
$this->request->getPost('email')—— 正常表单字段 -
$this->request->getPost('tags[]')—— 支持数组字段名，如<input name="tags[]"> -
$this->request->getJSON(true)—— 返回 PHP 数组（非对象），适合直接遍历 - 若用
getPost()去取 JSON 请求体里的字段，结果恒为null
别在控制器方法签名里硬塞 POST 参数
像 public function save($name, $email) 这种写法看似方便，实则危险。CI 不会自动把 POST 数据映射过去，它只解析 URI segment（如 /save/john/email@example.com），和 POST 无关。你看到的“能取到”，其实是巧合——因为 PHP 允许未声明变量被赋值，但变量作用域混乱、无类型约束、XSS 过滤失效。
容易踩的坑：开发环境没开严格模式，上线后报 Undefined variable；或者用户提交恶意脚本，绕过所有过滤直入变量。
- 所有 POST 数据必须显式调用
post()或getPost()获取 - 需要校验时，搭配
$this->validation->run()更可靠 - URI 参数和 POST 参数永远分开处理，不要指望框架自动合并
数组型 POST 字段要小心 key 名写法
循环生成的表单，比如多行输入：<input name="items[0][name]"><input name="items[0][price]">，CI 的 post() 和 getPost() 都能原样还原嵌套结构，但前提是 name 属性语法合法、没拼错中括号。
性能影响不大，但兼容性差：如果前端传了 items[0].name（点号）或 items[0][name（缺右括号），CI 会静默丢弃整个字段，不报错也不警告。
- 推荐用扁平 key：如
items_0_name，后端再用array_filter聚合 - 调试时用
var_dump($this->input->post())或print_r($this->request->getPost())看原始结构 - CI 4 的
getPost()对非法嵌套 key 返回null，不是空数组，注意判空方式
实际项目里最常出问题的，是开发者以为 POST 参数能像 GET 一样从 URI segment 里捞出来，或者把 post() 和 getJSON() 当成可互换接口。它们底层走不同解析路径，混用等于白做安全过滤。
