桥接方法是编译器为解决泛型擦除或协变返回导致的签名不匹配而生成的重写适配方法，字节码中同时标记ACC_BRIDGE和ACC_SYNTHETIC；合成方法范围更广，仅需ACC_SYNTHETIC，如内部类access方法、Lambda私有方法等。
Java 中的 synthetic 方法 和 bridge 方法 都是编译器在字节码层面自动插入的辅助方法，但它们的生成动因、语义角色和标识标志并不相同。关键区别在于：所有 bridge 方法一定是 synthetic 的，但 synthetic 方法不一定是 bridge 的——bridge 是 synthetic 的一个子集，且带有额外的语义约束。
bridge 方法的 Flag 特征
桥接方法由编译器在泛型擦除或协变返回类型等场景下生成，用于维持 JVM 层面的方法重写契约。它在字节码中同时具备两个标志：
- ACC_BRIDGE：专用于标识该方法是桥接方法（JVM 规范定义）
- ACC_SYNTHETIC：表示该方法非源码编写，由编译器合成（所有 bridge 方法都带此标志）
例如，实现 Comparable<String> 的类中，compareTo(Object) 方法的 flags 为 ACC_PUBLIC | ACC_BRIDGE | ACC_SYNTHETIC。调用 method.isBridge() 返回 true，method.isSynthetic() 也必为 true。
synthetic 方法的 Flag 特征
合成方法范围更广，只要编译器为实现语言特性而“悄悄添加”的方法，都属于 synthetic。它只依赖一个标志：
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
-
ACC_SYNTHETIC：这是唯一必需标志；不带
ACC_BRIDGE
典型例子包括：
– 内部类访问外部类私有字段时生成的 access$100(Outer) 静态包级方法
– Lambda 表达式编译后生成的私有静态方法（如 lambda$main$0(String)）
– 枚举类中自动生成的 values() 和 valueOf(String)（注意：这两个是 public 且 非 synthetic，属例外；真正 synthetic 的是枚举构造器里隐式调用的合成初始化逻辑）
如何通过反射准确区分二者
不能仅靠 isSynthetic() 判断是否为桥接方法。正确做法是组合判断：
-
method.isBridge() == true→ 确定是桥接方法（同时也一定是 synthetic） -
method.isSynthetic() && !method.isBridge()→ 纯合成方法（非桥接） -
!method.isSynthetic()→ 源码中明确定义的方法（用户编写）
Spring、MyBatis、SonarLint 等框架常使用 !method.isBridge() && !method.isSynthetic() 过滤掉这两类编译器注入方法，只保留开发者意图暴露的“真实方法”。
常见误区澄清
有人误以为“内部类生成的 access 方法是 bridge”，其实不是：它没有 ACC_BRIDGE 标志，也不参与方法重写语义，仅解决访问控制问题，纯属 synthetic。
同样，Lambda 编译出的方法标记为 ACC_PRIVATE | ACC_STATIC | ACC_SYNTHETIC，但绝不会带 ACC_BRIDGE——因为它不承担桥接签名的任务。
