php中public变量并非“随便用”的公共区域，而是无访问控制、无类型校验、全量暴露的开放接口，易导致安全漏洞，仅适用于纯数据容器或只读配置等受限场景。
PHP public变量为什么不是“随便用”的公共区域
PHP里的public不是“共享文件夹”，而是“谁都能伸手拿、也能随手改”的开放接口。它不校验调用方身份，也不拦截非法赋值——只要在作用域内，$obj->prop就能读写，连类型都不拦。
常见错误现象：Fatal error: Uncaught Error: Cannot access protected property User::$password反而让人安心；但public $password被前端表单直接映射、JSON自动填充、序列化反序列化一路透传，漏洞就藏在“没报错”里。
- 使用场景：仅适用于纯数据容器（如DTO）、配置对象（只读初始化后不再变更）、或明确设计为开放状态的字段（如
public $is_enabled且有setter约束） - 参数差异：
public字段在json_encode()、get_object_vars()、serialize()中默认全量暴露，而protected/private需显式定义__sleep()或JsonSerializable - 性能影响几乎为零，但安全兜底成本飙升：每个
public字段都得在业务逻辑层补校验，否则等同于把数据库字段直接挂到HTTP请求体上
public变量遇上魔术方法时的隐性越权
__get()和__set()不会自动接管public属性——这是最常被误解的一点。声明了public $name，哪怕类里写了__set()，对$obj->name = 'xss'依然完全放行，__set()根本不会触发。
真实案例：某用户中心类用public $avatar_url存头像地址，前端传{"avatar_url": "<script>..."}</script>，服务端直接入库，后续模板渲染直接执行JS。
立即学习“PHP免费学习笔记（深入）”；
- 如果需要拦截/转换/校验，必须把字段改成
private $avatar_url，再提供setAvatarUrl()方法做过滤 -
__set()只对protected/private且未定义的属性生效；对已声明的public属性，它彻底失效 - 别依赖
__debugInfo()来“隐藏”public字段——它只影响var_dump()，不影响JSON、序列化、反射或直接访问
框架里public变量如何意外暴露敏感信息
Laravel的Model、Symfony的Entity、ThinkPHP的Model都默认把public属性当可填充字段。一个public $api_token，可能被Model::create($request->all())直接写进数据库。
错误示范：class ApiKey extends Model { public $api_token; } —— 这等于给攻击者开了个INSERT通道。
- Laravel中，
$fillable白名单只控制create()/fill()，但public属性仍可通过$model->api_token = $input绕过 - ThinkPHP的
allowField同理，不拦直接赋值 - 所有ORM都遵循“public = 可写”约定，别指望框架替你守住这道门
什么时候可以放心用public变量
只有两种情况真正安全：值不可变，或值无业务含义。
比如public const VERSION = '2.1.0'没问题；public $created_at如果只在构造时设一次、之后只读，也勉强可控（但建议用readonly属性或getter封装）。
- 绝对避免：含密码、token、权限标识、用户输入原始内容的
public字段 - 谨慎使用：含计算结果的
public字段（如public $total_price），因为外部可篡改导致后续逻辑错乱 - 替代方案优先级：private + getter/setter > readonly属性（PHP 8.1+）> public（仅限POPO、配置类等无副作用场景）
复杂点在于，public变量的安全边界不在语法层面，而在整个调用链路是否可信——从HTTP请求、到框架填充、到业务处理、再到序列化输出，任何一环失控，它就是个裸奔的入口。
