Activator.CreateInstance 不能直接当 DI 容器用，因为它无法自动解析构造函数依赖、不维护生命周期，也不支持类型映射与泛型闭包处理，需手动构建依赖树且易出错。
为什么 Activator.CreateInstance 不能直接当 DI 容器用
它能创建实例，但没法自动解析构造函数里的依赖，更不维护生命周期。你传一个 IService 进去，它只会报 MissingMethodException 或 ArgumentException —— 因为没告诉它“这个接口该用哪个实现类来填”。
实操建议：
- 别在构造函数参数里留抽象类型（如
ILogger）就直接调Activator.CreateInstance，它不认识注册关系 - 若真要手动凑，得先查好依赖树，按顺序一个个 new 出来再传进去，容易漏、难维护
- 真正做注入时，必须自己维护一个映射表：比如
typeof(ILogger)→typeof(ConsoleLogger)
怎么用 TypeInfo 和 ConstructorInfo 扫出依赖链
核心是拿到目标类型的构造函数，再遍历它的参数类型，逐层递归 resolve。.NET Core 里常用 GetConstructors() + GetParameters()，但注意：有多个构造函数时，默认取最长的那个（不是 public 第一个）。
常见错误现象：InvalidOperationException: Unable to resolve service for type 'IRepository' while attempting to activate 'UserService' —— 其实就是某一级参数没在你的字典里注册。
实操建议：
- 只扫描
public构造函数，忽略private或internal的，否则可能意外触发副作用 - 遇到泛型类型（如
IRepository<user></user>），检查注册表时要用IsGenericType和GetGenericTypeDefinition()匹配，不能直接比typeof - 缓存已解析过的类型，避免重复反射开销；
ConcurrentDictionary<type object></type>比Dictionary更安全
ServiceCollection 和手写容器在生命周期上的关键差异
手写容器如果只返回 new 出来的对象，那每次 Resolve 都是新实例 —— 等同于 Transient。但你没法自然支持 Scoped（比如 HTTP 请求级单例），因为没上下文绑定机制。
性能影响很明显：没作用域管理的容器，在 Web 场景下可能把 DbContext 多次 new 出来，引发连接泄漏或并发异常。
实操建议：
- 若坚持手写，至少区分三种注册方式：
AddTransient（每次都 new）、AddSingleton（首次 new 后缓存）、AddScoped（需外部传入 scope 对象，比如AsyncLocal<dictionary object>></dictionary>） - 不要在
AddSingleton里注册含Transient依赖的对象，否则会把 transient 对象也“升格”成单例，导致状态污染 -
Dispose管理必须显式做：缓存的 singleton 实例要收集起来，统一调IDisposable.Dispose()，否则资源不释放
反射注入时最容易被忽略的泛型闭包问题
比如你注册了 typeof(IRepository) → typeof(EntityFrameworkRepository)，但实际 resolve IRepository<user></user> 时，如果不手动调用 MakeGenericType，就会拿不到正确类型，最终抛 InvalidCastException 或返回 null。
这不是语法错误，是类型系统层面的断连 —— IRepository<user></user> 和 IRepository 在 CLR 里是完全不同的 Type 对象。
实操建议：
- 注册开放泛型时，存的是
Type.GetGenericTypeDefinition()，resolve 时用genericDef.MakeGenericType(arguments)构造闭合类型 - 参数类型数组要严格对应：顺序、数量、是否可空（
int?和int是不同 Type） - 别依赖
GetType().Name做匹配，它不包含泛型参数信息；必须用FullName或直接比Type引用
泛型类型匹配和生命周期管理这两块，写错不会当场编译失败，但会在运行时某个边缘请求里突然崩掉，而且堆栈还藏得深。
