绝大多数情况下不该带错误码，因$code不参与catch匹配且易被误用；需类型区分应自定义异常类，结构化信息应放$message或额外属性而非$code。
PHP里throw new Exception到底该不该带错误码
绝大多数情况下，不用传第二个参数（错误码）。PHP的Exception类构造函数签名是__construct(string $message = "", int $code = 0, Throwable $previous = null)，但$code在实际捕获和日志中几乎不被框架或监控系统依赖——它既不参与类型判断，也不影响catch匹配逻辑。
常见错误现象：有人模仿Java习惯传404、500这类HTTP状态码，结果在catch (Exception $e)里根本没法靠$e->getCode()做业务分流，反而让后续维护者误以为这是标准协议。
- 真要区分异常类型，用自定义异常类继承
Exception，比如class ValidationException extends Exception - 需要结构化信息时，把上下文塞进
$message或额外属性（如$e->context = ['user_id' => 123]），而不是塞进$code - 某些老项目用
$code做简单分类（比如1表示参数错、2表示DB错），但这种做法在PSR-3日志或Sentry上报里基本丢失语义
什么时候必须用throw new Exception而不是trigger_error
trigger_error只能触发E_USER_WARNING或E_USER_NOTICE，它们不能被try/catch捕获，只走错误处理器。如果你需要中断当前执行流并由上层决定重试、降级或转跳页面，就必须用throw new Exception。
典型使用场景：API接口里验证失败、数据库写入前校验不通过、调用第三方服务返回不可恢复错误。
- Web请求中，
trigger_error('xxx', E_USER_ERROR)会直接500，但无法被Laravel的ExceptionHandler或Slim的错误中间件接管 - CLI脚本里想统一记录+退出码，
throw后在最外层catch里exit(1)比分散的die()更可控 -
set_error_handler可以捕获trigger_error，但无法中断后续代码——而throw天然具备控制权移交能力
throw new Exception里$message怎么写才不算埋雷
别写“操作失败”“系统错误”这种废话。消息内容要满足两个条件：对开发者可定位（含关键变量值）、对用户不可见（不暴露路径/SQL/敏感字段）。
容易踩的坑：把用户输入原样拼进$message，导致日志里满屏手机号、邮箱；或者写成"查询用户失败"，结果查的是订单表。
- 推荐格式：
"Failed to update order #{$orderId} status: expected 'paid', got '{$currentStatus}'" - 敏感字段用
md5()或占位符代替，比如"Invalid token prefix: '***{substr($token, -4)}'" - 避免在
$message里拼接完整SQL或堆栈，这些应该交给error_log()或Monolog的context参数
PHP 8.0+ 的throw表达式和传统语句有啥区别
PHP 8.0允许把throw当表达式用，比如$name = $_GET['name'] ?: throw new InvalidArgumentException('name required');。但它不是语法糖，而是改变了执行模型——这个throw会立即终止整个表达式求值，且不能被同一作用域内的catch捕获（因为不在try块内）。
性能上没差异，但可读性风险高：团队里有人可能误以为这行能被外层try兜住，结果抛出未捕获异常。
- 只在短路逻辑（
&&/||/?:）里用，别用在函数参数或数组赋值中 - IDE和静态分析工具（如PHPStan）对表达式
throw的支持还不完善，可能报错“ unreachable code” - 如果项目还要兼容PHP 7.4，这条语法直接报错，CI会挂掉
真正难处理的从来不是throw本身，而是没人检查catch块里是不是只写了echo $e->getMessage()就完事——那跟没抓一样。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
