不一定。php 8.4 起支持原生 get/set 属性访问器，可替代手动 getter/setter；8.3 及更早版本是否必须写，取决于封装强度、类型安全与维护成本的实际需求。
不一定。PHP 8.4 起，get 和 set 属性访问器（Accessors）已原生支持，可完全替代手动写的 getter/setter 方法；而 PHP 8.3 及更早版本中，是否必须写，取决于你对封装强度、类型安全和维护成本的实际要求。
PHP 8.4 中用 Accessors 替代 getter/setter 的真实约束
Accessors 不是“语法糖”，它在编译期绑定逻辑，不经过 __get()/__set() 魔术方法，因此有明确限制：
- 只能用于
public属性 ——protected或private属性不能直接声明get/set块 - 访问器内不能引用未声明的属性名；
$this->value是隐式底层存储变量，仅在访问器作用域内有效，不可在类其他地方读写 - 不支持条件性启用：比如“仅当开启调试才触发日志”，因为访问器逻辑是硬编码进属性定义的，无法运行时开关
- 若需兼容 PHP ParseError: syntax error
什么时候还必须手写 getter/setter
以下场景下，即使你用的是 PHP 8.4，仍得保留传统方法：
- 需要操作
private或protected属性 —— Accessors 只能挂载在public属性上，而真正封装的核心恰恰是隐藏这些属性 - getter/setter 逻辑依赖外部服务（如 Redis 缓存、数据库查询），且该逻辑不能简单用箭头函数表达
- 需在 setter 中触发事件（如
$this->dispatch(new UserUpdated($this))），而 Accessors 的set块不支持多语句（除非用完整函数体，但此时已接近手写方法的复杂度） - ORM 映射要求字段名与数据库列名分离（如属性叫
$fullName，但映射到 DB 列full_name），Accessors 无法改变序列化行为，仍需通过jsonSerialize()或自定义 hydrator 配合传统方法
PHP 8.3 及更早版本：不写 getter/setter 的代价
如果你跳过封装、直接暴露 public 属性，问题不是“能不能跑”，而是：
- 类型无法强制：即使声明
public int $age，赋值$user->age = "25"在弱类型上下文中仍可能静默发生，setter 才能做is_int()或类型转换 - 验证逻辑分散：年龄范围校验、邮箱格式检查、密码哈希等，若不在 setter 里做，就会散落在控制器、表单请求类甚至前端 JS 中，极易漏掉
- 无法实现只读/惰性计算：比如
$user->fullName应拼接firstName和lastName，但 public 属性无法动态生成，只能靠getFullName() - 单元测试难覆盖：直接赋值绕过所有业务规则，mock 行为也更复杂
一个务实的混合策略
不必非黑即白。实际项目中常见折中做法：
- DTO 类、API 响应类等纯数据载体，用 PHP 8.4 Accessors +
public属性，简洁安全 - 领域模型（如
User、Order），坚持private属性 + 手写 getter/setter，确保核心不变量受控 - 在 setter 内部调用私有验证方法（如
private function assertValidEmail(string $email): void），避免重复逻辑 - 若团队已用 Lombok 式工具（如 PHPStan 插件或自定义 AST 重写器），可考虑生成基础 getter/setter，再人工补业务逻辑
最易被忽略的一点：Accessors 的 get 块里用 $this->value 读取的是当前属性的“原始值”，不是经过之前 set 处理后的值 —— 比如你在 set 里做了 trim()，但 get 若没显式返回 trim($this->value)，读出来的仍是未处理的原始字符串。这个隐式存储机制，比手写方法更难调试。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
