getter 应返回原始值还是处理后值取决于属性用途和封装目标：格式化、脱敏等场景应返回处理后值，暴露内部状态则返回原始值；PHP 8.4 中 get 返回值必须严格匹配属性声明类型，且不应含 IO 或重计算。
getter 应该返回原始值还是处理后值？
取决于属性用途和封装目标。如果 getter 是为格式化、脱敏或类型转换服务的，就该返回处理后值；如果只是单纯暴露内部状态且外部需原始数据，就该返回原始值。PHP 8.4 的 get => 语法默认不修改原始存储，但你可以主动加工——关键不是“能不能”，而是“该不该”。
- 日期类属性（如
$createdAt）：返回DateTime实例比返回字符串更安全，避免外部重复解析 - 敏感字段（如
$passwordHash）：getter 应该直接抛出Exception或返回null，绝不返回原始哈希值 - 名称类字段（如
$name）：若业务要求前端始终显示首字母大写，用get => ucfirst($this->value)是合理封装；但若搜索、排序等逻辑依赖原始大小写，那就不能在这里改 - 可空属性（如
private ?string $email）：getter 可以统一返回空字符串''而非null，避免调用方处处判空——前提是业务允许语义降级
PHP 8.4 Accessor 中 get 的返回值受什么约束？
受属性声明的类型约束。比如声明为 public string $name，那么 get => 表达式最终必须返回 string，否则会触发 TypeError。PHP 不会自动强制转换，也不会忽略类型声明。
- 错误写法：
public int $count { get => $this->value ?? '0'; }—— 返回字符串，与int类型冲突 - 正确写法：
public int $count { get => $this->value ?? 0; } - 若需宽松处理，应改用可空类型：
public ?int $count，再在get中返回null或整数 - 注意：
$this->value是隐式槽，它的类型由赋值时的set逻辑或初始值决定，但最终get输出必须匹配声明类型
什么时候不该在 getter 里做计算或 IO？
当 getter 被高频调用、或可能被序列化/反射/ORM 映射时。PHP 的 getter（包括 Accessor）没有语言级标记说明“有副作用”，所以调用方默认认为它是轻量、幂等、无 IO 的。
- 避免在
get里查数据库、读文件、调用远程 API —— 这会让对象行为不可预测，也破坏 lazy loading 的明确性 - 避免复杂计算（如递归树展开、正则全量匹配），除非你明确记录并约定该属性是“计算属性”
- ORM 场景下尤其危险：很多框架会遍历所有 public 属性做映射，若某个
get触发查询，可能引发 N+1 问题而不自知 - 调试时也容易踩坑：
var_dump($user)或 IDE 变量面板会触发所有 getter，卡住或报错
传统 getter 方法 vs PHP 8.4 Accessor 的返回差异
表面看都是“读属性时执行逻辑”，但底层契约不同：传统方法是显式接口（$user->getName()），调用方清楚有逻辑介入；而 Accessor 是隐式拦截（$user->name），调用方以为在读字段——所以它的返回更需要克制。
立即学习“PHP免费学习笔记（深入）”；
- 传统方法可以返回任意类型，甚至改变语义（如
getName()返回['first' => 'John', 'last' => 'Doe']） - Accessor 的返回值应尽量贴近属性声明的直觉含义：一个
string $title的get就该返回字符串，而不是数组或对象 - 如果你发现需要在
get里做太多事，比如条件分支、多态判断、上下文依赖，那大概率该拆成独立方法（如getDisplayName()），而不是塞进 accessor - Accessors 的优势是“透明增强”，不是“重载语义”——越接近字段直觉，越不容易被误用
get 语法，而是判断哪部分逻辑属于“访问时必然发生”，哪部分其实该推给使用者或单独方法。很多人把验证、日志、缓存都塞进 getter，结果让最简单的读操作变得沉重又隐蔽。 
