php 7.3 不支持类属性类型声明，其默认 public 的未修饰属性实为封装隐患；应通过静态分析、构造函数脱节检查、getter/setter不对称扫描及废弃警告定位滥用场景。
PHP 7.3 本身不支持类属性的类型声明（该特性从 PHP 7.4 起引入），但已强制要求更严谨的访问控制意识。识别“滥用默认访问属性”，本质是发现本应受控却未显式声明可见性的类成员——即那些未加 public、private 或 protected 修饰符的属性，它们在 PHP 中**默认为 public**，这极易导致封装泄露。
检查类属性是否缺失显式访问修饰符
PHP 7.3 允许省略访问控制关键字，但语义上等同于 public。这类写法虽能运行，却是重构隐患的起点：
- 搜索所有
class定义中形如var $name;、$name;或public $name;但无明确封装意图的字段 - 特别注意
var声明（PHP 4 遗留语法），它在 7.3 中仍有效但已被标记为过时倾向，且隐含public - 用静态分析工具（如 PHPStan、Psalm）配置规则检测无修饰符属性，例如 Psalm 的
PropertyNotSetInConstructor或自定义规则匹配/^\s*\$(\w+)/m前无访问关键字的行
关注构造函数与属性初始化的脱节
若属性被直接赋值但未在 __construct() 中初始化，或仅靠外部调用 setter 设置，说明该属性本应私有并由可控路径写入：
- 检查属性是否在类内其他方法中被读写，但从未在构造函数中赋予初始值或校验逻辑
- 发现
$this->prop = $_POST['x']类型的直赋操作，而无类型约束或过滤——这是滥用public或默认public的典型信号 - 对比同名 setter 方法是否存在；若无，则该属性大概率被外部随意修改
扫描 getter/setter 不对称或缺失的访问模式
一个设计良好的类，若提供 getFoo() 却没有 setFoo()，或反之，往往暗示属性本应为 private，但因历史原因裸露：
- 用 IDE（如 PhpStorm）的“Find Usages”功能统计每个属性被直接访问（
$obj->prop）的次数；若远高于通过方法访问的次数，即为风险点 - 检查是否存在只读属性逻辑（如 ID、创建时间），却声明为可写——这通常源于默认
public后未收敛访问入口 - 留意注释中出现 “// DO NOT MODIFY DIRECTLY” 或类似提示，这是开发者已意识到问题但尚未修复的明显线索
结合 PHP 7.3 废弃提示辅助定位
PHP 7.3 对部分松散写法发出废弃警告，这些警告常与访问控制松懈共存：
- 启用
error_reporting(E_ALL | E_DEPRECATED)运行测试用例，捕获如var $x声明、大小写不敏感常量等废弃用法——它们常出现在老旧、缺乏封装意识的类中 - 检查是否使用了
assert()在命名空间中重定义，这类非常规做法往往伴随对类结构随意性容忍，间接反映访问控制薄弱 - 若项目仍在用
fgetss()或strip_tags流过滤器，说明整体代码规范滞后，需同步审查其所在类的属性访问方式
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
