正确扫描包路径下类需用classloader获取url并区分file/jar协议遍历，转换包名为路径、过滤非class文件及内部类；di容器应优先构造器注入，递归解析参数类型匹配bean，校验循环依赖，按@component推导bean名，避免字段注入隐患。
扫描指定包路径下所有类的正确姿势
Java 没有原生的包扫描能力，得靠 ClassLoader + URL 解析 + 文件系统或 JAR 包遍历实现。常见错误是直接用 Class.forName("com.example.*") —— 这根本不能通配，会抛 ClassNotFoundException。
实际要做的：从 ClassLoader.getResource() 拿到包路径对应的 URL，判断是 file: 还是 jar: 协议，再分别用 File.listFiles() 或 JarURLConnection.getJarFile().entries() 提取类名。
- 包名转路径时，必须把
.替换为/，末尾加/（如com/example/service/） - 扫描结果里过滤掉非
.class文件，且需去掉路径前缀、截掉.class后缀，再把/换回.才能得到合法类名 - 跳过内部类（含
$符号）、接口、枚举、抽象类（除非你明确想托管它们）
用反射安全实例化带依赖的构造器
不能无脑调 clazz.getDeclaredConstructor().newInstance() —— 一旦构造器参数不为空，就抛 InstantiationException 或 NoSuchMethodException。DI 容器的核心在于：递归解析构造器参数类型，并从已知 bean 集合中匹配、注入。
关键点是参数类型匹配逻辑：不是字符串比对，而是用 parameter.getType() 去查容器中是否已有该类型的实例（支持接口 → 实现类映射，但需提前注册或按默认规则选一个）。
立即学习“Java免费学习笔记（深入）”；
- 构造器必须设为可访问：
constructor.setAccessible(true)，否则私有构造器直接失败 - 避免循环依赖：检查当前正在创建的类是否已在“创建中”集合里，有则抛
BeanCurrentlyInCreationException（自定义异常） - 参数为基本类型（如
int）或不可实例化的类型（如String）时，应跳过自动注入，留待 @Value 或手动配置
@Component 注解识别与 Bean 名称推导
只扫描类没用，得识别哪些类该被当 bean 管理。最简方案是依赖 @Component（或其派生注解如 @Service），而不是靠命名约定或 XML 配置。
反射读取类上的注解很简单：clazz.isAnnotationPresent(Component.class)；难的是 bean 名称生成 —— 默认应取类名首字母小写（如 UserServiceImpl → userServiceImpl），而非简单 toLowerCase()（那样会把 XMLParser 变成 xmLparser）。
- 若类上显式写了
@Component("xxx")，优先用括号里的值 - 不要依赖
BeanDefinition或 Spring 的BeanNameGenerator，那是黑盒；自己写一个首字母小写工具方法更可控 - 同类型多个 bean 时（比如两个
DataSource实现），不处理名称冲突会导致后注册的覆盖前一个 —— 至少要检测并报错
字段注入 vs 构造器注入：为什么这里只做构造器
字段注入（@Autowired private XxxService service;）看着方便，但在纯反射容器里隐患大：它要求先 new 出实例，再 setAccessible + set，而此时对象可能处于不一致状态（比如某字段未赋值导致后续方法 NPE）；更重要的是，它破坏了不可变性，也难以做 final 字段支持。
构造器注入天然强制依赖声明、便于单元测试、能配合 final 字段使用。简易 DI 容器如果连构造器都搞不定，字段注入只会让问题更隐蔽。
- 别碰
@Resource或@Inject，标准不统一，增加兼容成本 - 如果真需要字段注入，必须确保字段是非 final 的、类型可被容器解析，且要在所有构造器注入完成后再统一处理
- 最易被忽略的一点：字段注入无法解决循环依赖（A 依赖 B，B 依赖 A），而构造器注入在发现时就能立刻报错，反而更利于定位
真正麻烦的从来不是怎么扫到类，而是怎么让每个构造器参数都精准对应到另一个已创建（或可递归创建）的 bean —— 类型擦除、泛型边界、原始类型与包装类混用，这些细节一漏，运行时才崩，debug 成本远高于写的时候多想两秒。
