正确做法是修改原异常的args后直接raise exc，不使用from；Go用%w保留底层错误类型；Java优先用带cause的构造器；JS用error.cause元数据。
Python 中用 raise ... from 会改变异常链，但不改类型
想保留原始异常类型（比如仍是 ValueError），又想附加上下文信息，不能靠修改 args 或新建同名异常——那样容易丢失 traceback 或触发误判。正确做法是用隐式异常链：raise 后不跟 from，而是先修改原异常的 args，再重新抛出。
- 直接改
exc.args = (exc.args[0] + " [context: db timeout]",)，然后raise exc - 注意：如果
exc.args是空元组或非字符串首项，先转成字符串再拼接，否则可能报TypeError - 这种做法不会触发
__cause__或__context__，所以except ValueError仍能精准捕获
Go 里用 fmt.Errorf 包装时保留底层错误类型
Go 没有“异常类型继承”概念，但标准库鼓励用 errors.Is 和 errors.As 判断底层错误。所以包装时要用 %w 动词，而不是 %s：
err := doSomething()
if err != nil {
return fmt.Errorf("failed to process user %d: %w", userID, err)
}
-
%w会让新错误实现Unwrap()方法，使errors.As(err, &target)能命中原始错误类型 - 若用
%s，原始错误被转成字符串，errors.As就失效了 - 多个
%w只能有一个，嵌套过深会影响性能，一般不超过两层
Java 的 addSuppressed 不适用，该用 initCause 或构造器传参
addSuppressed 是为 try-with-resources 的多重异常设计的，它不改变主异常类型，但也不附加到消息里；真要加文本报错信息，得走初始化路径：
- 如果异常类支持带
Throwable cause的构造器（如IOException(String, Throwable)），优先用它，既保类型又留链 - 否则用
initCause()，但必须在构造后立即调用，且只能调一次，否则抛IllegalStateException - 别手动拼
getMessage() + " extra"后塞进新异常——新异常类型变了，下游instanceof就断了
JavaScript 的 error.cause 是补充字段，不影响 instanceof
ES2022 起支持 cause 选项，它纯粹是元数据，完全不影响类型判断：
try {
riskyOperation();
} catch (err) {
throw new TypeError("Validation failed for input", { cause: err });
}
- 新抛出的仍是
TypeError实例，err instanceof TypeError为true -
err.cause可访问原始错误，但需运行时检查是否存在（旧环境无此属性） - Node.js 16.9+、Chrome 93+、Firefox 91+ 支持；不支持时可降级为
err.original = originalErr，但别覆盖内置属性名
最易被忽略的是：所有语言里“附加信息”都不该破坏原始错误的可序列化结构——比如 Python 的 __dict__ 扩展、Go 的自定义字段、Java 的非 transient 字段，都可能让日志系统或 RPC 框架丢掉关键上下文。
