getModifiers()返回整数位掩码而非字符串，需用Modifier类解码；包级私有对应0但需排除法判断；构造方法不支持static/final等修饰符，合法值仅限0、1、2、4及组合。
getModifiers 返回的是整数，不是字符串
调用 Constructor.getModifiers() 得到的是一个 int 值，它把 public、protected、private 等修饰符编码成位掩码（bitmask），不是直接返回 "public" 这样的字符串。直接打印或比较这个数字会看到像 1、2、4 这样的值，容易误以为是序号或错误码。
正确做法是用 Modifier 工具类来解码：
int mods = ctor.getModifiers();
if (Modifier.isPublic(mods)) { /* 是 public */ }
if (Modifier.isPrivate(mods)) { /* 是 private */ }
if (Modifier.isProtected(mods)) { /* 是 protected */ }常见对应关系：Modifier.PUBLIC == 1，Modifier.PROTECTED == 4，Modifier.PRIVATE == 2 —— 注意顺序不按字母，数值也不连续。
不能靠 getModifiers 判断 default（包级私有）
getModifiers() 对于包级私有（即没写任何访问修饰符）的构造方法，返回值是 0。但它**不会告诉你“这是 default”**，因为 Java 的修饰符常量里根本没有 Modifier.DEFAULT。你只能通过排除法判断：
!Modifier.isPublic(m) && !Modifier.isPrivate(m) && !Modifier.isProtected(m)- 且
m == 0
这俩条件同时成立，才基本可认为是包级私有。但要注意：如果构造方法还带其他非访问修饰符（比如 static），getModifiers() 的返回值就不再是 0，而会包含额外位（Modifier.STATIC == 8），这时就不能只看是否为 0 了。
和 Method.getModifiers 行为一致，但语义不同
Constructor.getModifiers() 和 Method.getModifiers() 返回值类型、解码方式完全一样，都用 Modifier 类处理。但语义上差异很大：
- 构造方法不可能是
static或final（编译器禁止），所以返回值中永远不会有Modifier.STATIC或Modifier.FINAL的位被置起 - 构造方法可以是
synchronized，对应Modifier.SYNCHRONIZED == 32，但极少用，多数框架（如反射创建实例）会忽略它 -
native、abstract、strictfp在构造方法中非法，不会出现在返回值中
也就是说，对构造方法而言，getModifiers() 实际只可能返回 0、1、2、4、5（public + protected）、6（private + protected）等组合，超出这些范围的值通常意味着代码有误或 JVM 实现异常。
获取修饰符前必须确保构造方法可访问
反射默认受 Java 访问控制限制。如果目标构造方法是 private，而调用方不在同一类中，getDeclaredConstructor(...) 能拿到对象，但直接调用 getModifiers() 不会报错；真正出问题的是后续的 newInstance() 或 setAccessible(true)。
不过，有个隐性坑：某些安全策略（如运行在 SecurityManager 下，或模块化系统中未开放包）可能导致 getDeclaredConstructor 抛 SecurityException，此时根本拿不到 Constructor 实例，更别说调用 getModifiers() 了。
稳妥做法是：
- 先用
getDeclaredConstructors()获取全部，再逐个检查 - 对每个
Constructor，先setAccessible(true)（如果需要后续调用），再读getModifiers() - 别假设
getModifiers()会抛异常——它几乎从不抛，出问题一定在前面的获取或设置环节
修饰符本身只是元数据，Java 不会在读取时做访问校验；真正校验发生在实例化或设为可访问时。
