企业官网建设流程全解析

开头先聊一个现象：很多人一听到 IOC（控制反转）和 AOP（面向切面编程），第一反应是“这是重量级框架才有的东西，我们普通业务代码用不上”。但在 .NET 项目里，当你开始面对十几个服务互相依赖、每个接口都要写日志、每个方法都要做事务控制的时候，你会发现手写依赖注入和横切逻辑会让代码迅速变成一锅粥。Castle 这个老牌框架，能同时把 IOC 和 AOP 这两件事用非常轻量的方式落地，而且不需要你引入庞大的全家桶。今天这篇博文，我就拿一个实际的模拟项目 X 来做拆解，讲清楚怎么用 Castle 完成动态注入和动态代理，把 IOC 和 AOP 整合进现有代码。

我全程会以 .NET 6/8 环境为例，代码可以直接复制到项目里跑起来看效果。无论你是刚接触 DI 概念的新手，还是已经在用微软自带容器但觉得 AOP 无处下手的开发者，这篇内容都能给你一条比较顺畅的路径：先理解为什么要这样设计，再动手把核心代码写出来，最后一起看看那些文档里不会明说、只有实际踩过坑才会发现的细节。

1. 项目概述与核心需求拆解

1.1 标题里的三件事：IOC、AOP、动态代理到底是什么

先把这个标题拆开看：”.Net中使用Castle进行IOC+AOP（动态注入+代理）“，其实包含了三项技术要素。

说 IOC 的时候，我们说的是控制反转，也就是把对象的创建和依赖关系从自己代码里挪出去，交给容器统一管理。比如以前你写一个订单服务，里面new一个库存服务，这叫正向依赖；改成构造函数注入库存服务接口，让容器在实例化订单服务时自动把库存服务传进来，这就是控制反转。好处很直接：服务之间只剩接口契约，没有具体实现耦合，以后替换实现类、写单元测试都方便得多。

AOP 则是面向切面编程，它解决的是横切关注点的问题。日志、缓存、事务、权限校验这类逻辑，它们不属于任何一个业务模块，却又散落在每一个业务方法里。AOP 的思路是把这些逻辑统一提取出来，在不修改原方法的情况下，通过代理对象把额外行为“织入”到目标方法的前后。

那代理是什么？就是 AOP 落地的技术载体。你在容器里拿到的对象，可能表面上是某个业务类的实例，实际上是一个由 Castle 动态生成的子类或接口实现，这个代理类在调用目标方法前，会先执行你的拦截器逻辑，然后才进入真实的方法体。

所以这个项目标题其实是在描述一种组合架构：用 Castle 作为依赖注入容器，同时用 Castle 的动态代理能力做 AOP，两者都围绕“代理”这个词展开。

1.2 我为什么在项目中放弃了手写工厂类

先说一段个人经历：早先做一个某跨平台系统的接入层，没有用任何容器，所有服务都在一个很大的工厂类里通过 switch-case 分支返回实例。新接入一个渠道，就要改一次工厂方法，改动本身不难，但每次都要重新编译、重新发版，而且渠道一多，工厂类的代码膨胀得很快。更要命的是，每个接口方法都要自己做日志记录、异常包装，那段代码反复复制粘贴，后来实在维护不下去，才下定决心把 Castle 引进来。

Castle 让我比较满意的一点是：它不逼你把整个架构推倒重来。你可以只把工厂类里的实例化逻辑替换成容器注册，然后逐步把切面逻辑用拦截器接管。对老项目来说，这种渐进式改造策略比“大版本重构”安全得多。我觉得初期学习成本主要集中在理解容器生命周期和代理拦截机制这两个概念上，但只要弄清楚，后面扩展新的服务类型就很顺了。

1.3 适用项目类型与边界判断

Castle 这个方案适合什么样的项目？我先给一个相对清晰的判断。如果你的项目里有明显的业务分层需求，服务接口需要多个实现类且运行时才决定用哪一个，或者横切逻辑已经开始在代码里大量重复，那 Castle 的 IOC + AOP 组合是很合适的。比如订单中心、网关、支付渠道聚合这类系统，就很典型。

如果你的项目只是简单的 CRUD 接口，只有三五个类，也不想维护容器配置，那用微软自带的Microsoft.Extensions.DependencyInjection就够了，没必要引入 Castle。另外，如果项目对代理性能有极苛刻的要求（比如每秒几百万次调用且每个方法都在热路径上），Castle 动态代理的反射调用开销可能成为瓶颈，这时候需要谨慎评估。

2. 核心方案选型：为什么选择 Castle 而不是其他框架

2.1 那些年我用过的几种 AOP 实现方式

在讲 Castle 之前，先把几种主流 AOP 方案的优缺点列成一张表，方便大家理解我为什么最后还是选了 Castle。

可以用一个生活类比来理解这几种方案的区别：装饰器模式好比你在餐厅点完菜，服务员把菜端到你面前时，你发现旁边的加急牌可以贴上，但你每道菜都要手动贴；静态织入呢，像后厨直接把你的特殊要求烧进了菜里；而 Castle 动态代理，则像是一层透明的外卖包装盒，你从外面看不到厨房内部，但每一道菜出门前都会自动经过这道包装，添加额外的东西。

2.2 Castle 两大组件的职责边界

Castle 有两大核心组件：Windsor 和 DynamicProxy。很多人把这两个混在一起说，但它们其实是分层关系。

Windsor 是完整的 IOC 容器，负责注册、解析、生命周期管理。我们说的动态注入，主要体现在 Windsor 这一层。DynamicProxy 则是独立的代理库，不需要 Windsor 也能单独使用，它只负责生成代理类拦截方法。在同一个项目里，你可以只用 Windsor，也可以只用 DynamicProxy，但把它们结合起来才是完美的组合：用 Windsor 做依赖注册，顺便把拦截器挂到对应服务上，这样容器解析出来的对象天然是代理对象。

这个组合在架构上的意义在于：业务代码完全不需要感知拦截器的存在。你定义的接口是IOrderService，你写的实现类OrderService，你在注册时告诉 Castle “这个服务的实例化交给容器，并且为它加一个日志拦截器”，那么调用方通过构造函数拿到的IOrderService其实已经是代理类实例，调用方法时日志逻辑自动生效。

2.3 与微软自带 DI 容器搭配的方案

有些项目已经在用IServiceCollection做依赖注入，这时候引入 Castle 也不是二选一。比较稳妥的做法是：用微软容器负责基础服务和中间件的注册，单独引入 Castle DynamicProxy 来做代理拦截。因为 DynamicProxy 本身不需要 Windsor 就能工作，你可以在IServiceCollection的注册阶段，手动把代理工厂生成的代理对象注册进容器。

我实际项目里更常见的是“混搭模式”：Web API 层用微软自带 DI，业务服务层用 Windsor 管理比较复杂的那部分服务。要提醒的是，混搭时要注意容器边界，不要让 Windsor 解析出来的对象反过来依赖微软容器里的服务，否则容易出现容器不一致导致的问题。

3. 环境准备与基础搭建：5 分钟跑起第一个拦截

3.1 引入 Castle 相关包

用 .NET 6/8 时代，引入 Castle 很简单，直接用 NuGet 包管理器。要在命令行里执行的话，可以这样：

dotnet add package Castle.Windsor dotnet add package Castle.Core

Castle.Windsor这个包会同时依赖Castle.Core，后者包含DynamicProxy核心库。如果你只想用 AOP 不想用容器，安装Castle.Core就够了。版本方面，建议直接使用最新稳定版，目前 NuGet 上稳定版本迭代还是比较积极的。

一个容易被忽略的细节：Castle 的包名和命名空间不同，实际编写代码时using Castle.Windsor;是容器，using Castle.DynamicProxy;是代理相关接口。两者不要搞混。

3.2 用 WindsorContainer 做最小可运行的注入

先写一小段代码，感受一下 Castle 最小的运转方式。假设我们有一个模拟的订单服务：

public interface IOrderService { string Process(string orderId); } public class OrderService : IOrderService { private readonly IStockService _stockService; public OrderService(IStockService stockService) { _stockService = stockService; } public string Process(string orderId) { return $"订单 {orderId} 已处理，库存状态：{_stockService.CheckStock(orderId)}"; } } public interface IStockService { string CheckStock(string orderId); } public class StockService : IStockService { public string CheckStock(string orderId) { return "充足"; } }

容器注册与解析：

using Castle.Windsor; using Castle.MicroKernel.Registration; var container = new WindsorContainer(); container.Register( Component.For<IStockService>().ImplementedBy<StockService>().LifestyleSingleton(), Component.For<IOrderService>().ImplementedBy<OrderService>().LifestyleTransient() ); var orderService = container.Resolve<IOrderService>(); Console.WriteLine(orderService.Process("2024-001")); container.Release(orderService);

这段代码里LifestyleSingleton()和LifestyleTransient()分别对应单例和瞬态生命周期。Release方法负责释放对象，在 Windsor 里很重要，特别是对象实现了IDisposable时。基础跑通之后，才谈得上把拦截器加进去。

3.3 为 Windsor 加入拦截器支持

Windsor 自 3.0 版本开始原生支持拦截器注入，这是它相比其他 IOC 容器一个很大的优势。要启用拦截器，你不需要额外配置复杂的 XML 文件，在注册组件时会话式地指定即可。

不过在实际项目里，我建议先在顶层做一个继承IInterceptor的通用拦截器，再到业务代码里按需使用。从这一步开始，AOP 的价值才真正显现出来。

4. 动态注入的实现细节：从注册到解析的完整链路

4.1 注册方式逐个说：类注册、接口注册、约定注册

Windsor 的注册方式非常灵活，初期最容易理解的是按类型逐个注册。除了上面那种写死的Component.For<T>().ImplementedBy<U>()，还有更威风的基于约定的批量注册。

比如在一个业务层程序集里，你希望把所有后缀为Service的类都注册到对应接口：

container.Register( Classes.FromAssembly(typeof(OrderService).Assembly) .Where(type => type.Name.EndsWith("Service")) .WithServiceDefaultInterfaces() .LifestyleTransient() );

这里有个很容易踩坑的地方：.WithServiceDefaultInterfaces()默认注册的是类实现的第一个接口，如果类实现了多个接口，可能会发生“注册了但解析不到”的情况。更稳妥的写法是.WithServiceAllInterfaces()或者指定.WithService.Select()自定义规则。

配置管理技巧：Windsor 也有一个 XML 配置的传统用法，在 .NET Core 时代已经比较少见。我还是推荐在代码里用 Fluent API 做注册，编译期能发现错误，重命名也安全，不会出现运行时才爆出的字符串配置问题。

4.2 生命周期管理：Singleton、Transient、PerWebRequest 的取舍

IOC 容器的一个核心职责是管理对象生命周期。Castle Windsor 里概念上比较常用的有三种：

• LifestyleSingleton()：一个容器内只有一个实例，适合无状态服务、配置服务、基础设施类服务。
• LifestyleTransient()：每次解析都是新实例，适合需要短暂状态、无法共享的组件。
• LifestylePerThread()/LifestylePerWebRequest()：前者每个线程一个实例，后者每个 Web 请求一个实例，适合带有请求上下文状态的组件。

在实际项目里，我曾遇到过因为误把Service类注册成 Singleton，导致其中注入的DbContext被多个请求共享，最终出现数据库连接混乱的问题。按我的经验，一个稳妥的做法是：无状态服务用 Singleton，有状态且跟请求关联的用 PerWebRequest 或 Transient。

Castle 还一个很有价值的扩展点是自定义生命周期。如果你了解Castle.Core的ILifestyleManager接口，可以实现自己的释放策略，比如每个业务事务一个工作单元实例。这个进阶方向比较深，但值得多花时间研究。

4.3 Windsor 的装配过程发生了什么

每次执行Resolve时，Windsor 内部会做这样几件事：

1. 根据解析的类型查找注册信息。
2. 检查构造函数参数，找到可满足依赖的注册项，递归解析这些依赖。
3. 解析完毕后执行初始化操作，比如属性注入、拦截器附加。
4. 返回一个真正的实例或代理实例。

这里有一个微妙点：如果你注册了拦截器，Windsor 返回的就不是普通实例，而是一个动态代理。代理对象在第一次调用方法时才触达真实实例，所以构造函数中的依赖注入是即时发生的，但拦截器的AOP逻辑却是在方法调用时才会触发的。

理解这个时间差很重要，能帮助你排查出很多“为什么我在构造函数里看不到切面效果”之类的困惑。

5. AOP 拦截器实战：手写日志拦截器与性能监控

5.1 从 IInterceptor 接口开始

一个拦截器，实际上是 Castle 动态代理框架中的一个类，它实现IInterceptor接口。这个接口只有一个方法：Intercept(IInvocation invocation)。

using Castle.DynamicProxy; public class LoggingInterceptor : IInterceptor { private readonly ILogger<LoggingInterceptor> _logger; public LoggingInterceptor(ILogger<LoggingInterceptor> logger) { _logger = logger; } public void Intercept(IInvocation invocation) { var methodName = $"{invocation.TargetType.FullName}.{invocation.Method.Name}"; var stopwatch = Stopwatch.StartNew(); try { _logger.LogInformation("开始调用 {MethodName}，参数：{Args}", methodName, string.Join(",", invocation.Arguments)); invocation.Proceed(); stopwatch.Stop(); _logger.LogInformation("调用 {MethodName} 完成，耗时 {ElapsedMs} ms，返回值：{ReturnValue}", methodName, stopwatch.ElapsedMilliseconds, invocation.ReturnValue); } catch (Exception ex) { stopwatch.Stop(); _logger.LogError(ex, "调用 {MethodName} 失败，耗时 {ElapsedMs} ms", methodName, stopwatch.ElapsedMilliseconds); throw; } } }

写了几个注意点：

• invocation.Proceed()是核心动作，它会继续执行真实的业务方法。不调用Proceed，真实方法就不会执行，这在做短路拦截时很有用，比如缓存命中直接返回。
• invocation.Arguments是方法参数对象数组，如果要修改入参，可以在Proceed()之前改这个数组的元素。
• invocation.ReturnValue可以用来在方法执行之后修改返回值。
• 强烈建议在业务系统中把日志/性能监控做成一个独立的拦截器，不要跟业务逻辑混在一起。

5.2 代理类型与代理生成机制

Castle 生成代理有两种方式：基于接口的代理和基于类的代理。在 IOC 场景下，我们通常注册的是接口和实现类，因此 Windsor 默认会为接口生成一个实现该接口的代理类；如果你注册的是类本身（没有接口），Castle 会生成一个继承自该类的子类代理。

基于类的代理有几个限制：

• 目标方法必须是虚方法（virtual），否则无法重写。
• 目标类不能是 sealed。
• 构造函数的约束：Castle 会尝试调用某个构造函数来创建代理，默认会用带最多参数的构造函数。

在我自己的项目中，我尽量坚持面向接口编程，一个直接好处就是被代理的类不需要特意把方法标成 virtual，自由度大很多。而如果被迫要对具体类代理，记得所有需要拦截的方法都要加virtual修饰符，这是很多人容易搞错的地方。

5.3 让拦截器“挑活干”：选择性拦截特定方法

实际业务里，不是所有方法都需要拦截。一个系统服务可能有几十个方法，但只有订单支付和退款需要加事务拦截，查询方法不需要。Castle 给我们提供了几个切入点来控制拦截行为：

一是在注册时用.Interceptors()指定某个服务的拦截器列表，像这样：

Component.For<IOrderService>() .ImplementedBy<OrderService>() .Interceptors<LoggingInterceptor>() .LifestyleTransient();

二是拦截器内部根据invocation.Method.Name做过滤。更优雅的方式是用自定义特性标记，比如定义一个[NoLog]特性：

public class NoLogAttribute : Attribute { }

然后在拦截器中判断：

if (invocation.Method.IsDefined(typeof(NoLogAttribute), true)) { invocation.Proceed(); return; }

如果拦截器较多，还有更灵活的做法：注册多个拦截器时，Windsor 的执行顺序与注册顺序一致，但如果你希望方法级别更精细地控制，默认IInterceptorSelector接口可以深度控制代理对象在调用每个方法时选择哪些拦截器。不过对于绝大多数业务场景，用特性过滤已经足够。

6. IOC 与 AOP 的结合实践：动态代理的完整注入案例

6.1 创建带有拦截器的服务注册扩展方法

为了在真实项目里不把WindsorContainer的注册代码堆在入口处，我习惯封装一个扩展方法。比如这个：

public static class WindsorExtensions { public static void RegisterOrderServices(this IWindsorContainer container) { container.Register( Component.For<IInterceptor>() .ImplementedBy<LoggingInterceptor>() .LifestyleSingleton(), Component.For<ICacheInterceptor>() .ImplementedBy<CacheInterceptor>() .LifestyleSingleton(), Component.For<IOrderService>() .ImplementedBy<OrderService>() .Interceptors<LoggingInterceptor, ICacheInterceptor>() .LifestyleTransient(), Component.For<IStockService>() .ImplementedBy<StockService>() .Interceptors<LoggingInterceptor>() .LifestyleSingleton() ); } }

这样做的好处是：使用的入口处很干净，只管调用这个扩展方法；替换业务实现时只需要改这一处；拦截器组合更加可见。

关于拦截器顺序，这里有一个非常现实的例子：如果你先执行缓存拦截器，缓存命中时就可以跳过业务方法，日志拦截器也不会记录“第二次调用”；如果你先执行日志拦截器，则会先记录“开始调用”，再进入缓存判断。所以注册顺序不是随便写的，而是有业务语义考量的。

6.2 一个典型业务场景：缓存拦截器与数据库操作拦截器

动态注入和 AOP 的价值，只有在真实场景中才体现得彻底。我这里模拟一个订单查询和创建的业务场景，来映射缓存和事务切面。

先定义一个缓存拦截器：

public class CacheInterceptor : IInterceptor { private readonly ICacheProvider _cache; public CacheInterceptor(ICacheProvider cache) { _cache = cache; } public void Intercept(IInvocation invocation) { var cacheKey = $"{invocation.TargetType.FullName}.{invocation.Method.Name}:{string.Join("_", invocation.Arguments)}"; if (invocation.Method.ReturnType != typeof(void) && _cache.TryGet(cacheKey, out object cachedValue)) { invocation.ReturnValue = cachedValue; return; } invocation.Proceed(); if (invocation.ReturnValue != null) { _cache.Set(cacheKey, invocation.ReturnValue, TimeSpan.FromMinutes(5)); } } }

再写一个简单的事务拦截器：

public class TransactionInterceptor : IInterceptor { private readonly IUnitOfWork _unitOfWork; public TransactionInterceptor(IUnitOfWork unitOfWork) { _unitOfWork = unitOfWork; } public void Intercept(IInvocation invocation) { _unitOfWork.BeginTransaction(); try { invocation.Proceed(); _unitOfWork.Commit(); } catch { _unitOfWork.Rollback(); throw; } } }

这两个拦截器都是“完成一个独立关注点”的典型例子。把它们组合到服务上时，注册代码本身几乎不需要改动业务类。如果未来想把缓存从本地内存换成 Redis，只需要替换ICacheProvider的实现类，业务代码一行都不用动，这就是 IOC + AOP 的组合力量。

6.3 完整示例：解析服务、调用方法、观察拦截链

下面我把所有内容串起来，模拟一个完整的控制台调用：

var container = new WindsorContainer(); container.RegisterOrderServices(); var orderService = container.Resolve<IOrderService>(); // 第一次调用：日志拦截器记录，事务拦截器开启事务，真实业务执行，缓存写入 var result1 = orderService.Process("订单A"); // 第二次调用：缓存拦截器命中，直接返回结果，事务拦截器甚至不需要执行业务方法 var result2 = orderService.Process("订单A"); Console.WriteLine(result1); Console.WriteLine(result2); container.Release(orderService);

这里有个细节值得注意：第二次调用时Process方法返回结果相同，但如果你在日志拦截器里打印了方法执行，第二次可能只会看到缓存拦截器命中，而看不到业务方法执行日志。这一步有助于验证拦截器顺序是否正确。如果把缓存拦截器注册到日志拦截器后面，那每次请求都会先经过日志，再走缓存，日志量就大了，性能也有影响。

6.4 拦截器中依赖注入的注意事项

拦截器本身也是组件，它的构造函数里可以注入其他服务。Windsor 会像解析普通服务一样解析拦截器的依赖。但有几种特殊情况需要特别小心：

第一，拦截器注册为 Singleton 时，它注入的依赖最好是 Singleton。如果拦截器是 Singleton，而它注入了 Transient 服务，那么这个 Transient 服务实际上是“披着 Transient 外衣”的单例，因为它被单例拦截器长期持有。

第二，不要在没有注册拦截器的情况下让拦截器直接实现IDisposable并依赖容器释放，Castle 对拦截器的释放策略与你设定的生命周期有关，不建议手动释放拦截器实例。

第三，如果多个服务共用同一个拦截器实例（Singleton 模式），那拦截器内部不要保存与具体调用相关的状态，比如本次请求的用户信息。如果想按请求区分，可以在调用上下文中取数据，或把拦截器作为 Transient 注册。

7. 常见问题与排查技巧实录

7.1 代理不生效？先检查这五个地方

我从自己的踩坑经历出发，梳理一下“代理不生效”的高频原因，整理成一张排查表。

其中，基于类代理却缺少virtual这个问题，是我见过最多的。很多人从接口代理迁移到类代理时，很容易忽略这一点。判断方法也很简单：追踪一个方法是否被拦截，直接看它是否打印了拦截日志。

7.2 排查技巧：用一根探针看清楚拦截链路

当多个拦截器叠加时，我推荐在最前和最后各加一个极简的“探针拦截器”，只打印方法名和执行前后标记，不做任何业务。我实际操作时也见过有人通过这种方式定位出“某个拦截器把invocation.Proceed()调用漏掉了”这种隐蔽问题。

小技巧是这样：如果自定义拦截器里不小心漏写invocation.Proceed()，真实业务方法就不会执行，但代码不会报错，可能会表现为“接口调用成功但数据没有变化”。这种 bug 比崩溃更难定位。所以我甚至会在探针里把“是否调用了Proceed”也打印出来。

7.3 性能分析：动态代理到底慢不慢

很多人对动态代理有疑虑，怕反射调用影响性能。我实际测试过在上面这种普通业务场景下，动态代理的额外开销通常在微秒级别。一次日志输出加一次数据库访问轻易就超过这个量级，所以相比 I/O 操作，代理开销几乎可以忽略。

但如果你的方法体本身非常快（只是返回一个常量），且单循环调用几百万次，那代理占的时间比例就明显了。在这种情况下，可以考虑缓存代理对象、去掉不必要的拦截器、或者对极热路径方法单独走非代理的实例。有个更优雅的办法：在拦截器内部先用一个快速判断，对不需要走切面的方法直接Proceed()，不做任何额外逻辑。

7.4 释放与内存泄漏：容器需要正确 Release

Windsor 容器里，如果你解析的是一个实现IDisposable的对象，却不调用container.Release(obj)，会导致资源迟迟不能被回收。尤其在 Transient 生命周期下，每次Resolve都会创建新实例，不释放就会累积。

这里有一个容易被忽略的复杂点：当你拿到的是代理对象，Release时容器需要把代理和真实对象一起释放。最好的习惯是：每次Resolve都要记得在finally中Release。在 Web 项目中，可以使用 Windsor 提供的WindsorControllerFactory和相关的PerWebRequest生命周期插件自动释放，避免在每个 Controller 里手动处理。

说到容器与框架的集成，ASP.NET Core 里可以有专门适配 Windsor 的IServiceProviderFactory扩展，接管请求作用域。当然，这部分配置相对繁琐，如果你只是局部使用，比如某个后台任务或控制台程序，直接手动管理 Release 也完全没问题。

8. 踩坑后的经验总结与个人建议

先把我自己的体会直说了：Castle 的 IOC + AOP 组合，属于那种“初看复杂、用顺之后回不去”的技术组合。初期最耗时间的部分不是写代码，而是理解“容器里的对象可能并不是你以为的那个对象”，理解这一点之后，拦截器、生命周期、代理顺序这些问题就会串成一条线。

对于具体实践，我有这几个建议可以作为参考：

第一，新项目建议直接使用“接口 + 实现类 + 拦截器”的模式，从一开始就把横切逻辑隔离在业务类之外。哪怕最初没有复杂的横切需求，也留好拦截器注册的扩展点，后面加缓存、加日志、加事务都很自然，不用回头重构。

第二，老项目迁移时，不要一次性把服务类全部纳入容器。可以先选一个独立的业务模块做试点，把工厂类替换成 Windsor 注册，加上日志拦截器，观察一段时间确认没有异常，再逐步铺开。这样风险最小。

第三，建立一套标准命名规范。比如所有业务服务接口统一以I开头，实现类以Service结尾，拦截器以Interceptor结尾。命名规范能够支撑基于约定的批量注册，减少写代码时的决策成本。

第四，建议从一开始就写一个拦截器顺序注释，放在注册扩展方法的头部。这个注释能快速告诉后来的维护者，哪些拦截器在前哪些在后，以及为什么这个顺序不能随意调换。这个习惯在很多项目里都适用。

第五，如果遇到“注册了但解析报错”的异常信息，不要慌张。Castle 的异常信息虽然长，但它会把链路缺失的依赖类型写得很具体，比如service 'xxx' cannot be resolved，顺着提示检查构造函数参数和注册是否匹配就好。

再分享一个我在实际应用中验证过比较高效的小技巧：如果你临时要在某个方法上做性能监控，不必新写服务，只需注册一个临时拦截器，等收集完数据再移除。整个过程不会对业务代码有任何侵入，这个特性本身，就是 AOP 带给开发效率最大的红利。