使用嵌套的 ILifetimeScope 解析服务
Autofac 被设计为跟踪(track)和清理(dispose)资源。为确保资源被正确处理，务必将长时间运行的应用程序分成小的工作单元 (请求或事务)，服务的解析应在工作单元级别的生命周期范围中进行。为 asp.net 实现的每个请求一个生命周期范围 是这项技术的一个示例。
使用模块进行配置
Autofac 模块(module) 提供了一种组织容器配置的方式，并允许注入“部署时设置”。与 XML 配置相比，模块是更有弹性的方式。模块可以随时组合到 XML 配置中，提供两全其美的体验。
在委托注册中使用 As<T>() 方法
Autofac 从注册组件的表达式推断实现类的类型:
builder.Register(c => new Component()).As<IComponent>();
上面的代码中，组件的 LimitType 是 Component 类。以下两种类型转换的方式是等价的，但是未提供正确的 LimitType：
// 行的通，但应避免这种写法 builder.Register(c => (IComponent)new Component()); //行的通，但应避免这种写法 builder.Register<IComponent>(c => new Component());
使用构造函数注入
使用构造函数注入必需的依赖，使用属性注入可选的依赖，这个概念广为人知。但是，作为替代，也可以使用“空对象模式” 或 “特例模式” 为可选服务提供默认的，什么都不做的实现。这样可以减少组件实现中处理特殊情况的分支(比如 if (Logger != null) Logger.Log("message");).
使用关联类型，而不是服务定位器
将容器存在公共静态属性中，以便组件可以访问到容器，或在全局的“Ioc”类中提供诸如 Resolve() 之类的函数，这些做法会使依赖注入的意图落空。这样的设计实际上是服务定位器器模式。
如果组件有对容器(或生命周期范围)的依赖，请查看组件是如何使用容器获取服务的，然后将服务通过构造函数注入到容器中。
如果组件需要实例化其他组件，那么请为它使用关联类型 ，或者用更高级的方式同容器交互。
按照不特定到特定的次序注册组件
Autofac会覆盖组件注册。应用程序可以注册所有默认组件，然后读取配置文件，用定制的组件覆盖默认的版本。
使用 Profilers 检查性能
如果要进行优化，或怀疑内存泄漏，请首先使用profiler 工具（比如SlimTune, dotTrace, 或 ANTS）检查，确定程序时间到底消耗在哪里。很可能与设想的不同。
一次注册，多次解析
如有可能，请勿在工作单元执行过程中注册组件。注册组件的代价要远大于解析组件。使用生命周期范围和适当的实例范围使工作单元彼此隔离。
使用拉姆达表达式注册频繁使用的组件
如果确实需要榨取额外性能，最好的办法是标记出解析最频繁的组件，并使用拉姆达表达式注册代替类型注册：
builder.RegisterType<Component>();
改为:
builder.Register(c => new Component());
这可以让 Resolve 方法速度提高 10 倍，但是仅对出现在很多对象图中的组件有意义。请参考Aufofac中注册的概念。