IIS 7中policy与kernelCachePolicy的区别及配置考量

咱们先看你配置的这段输出缓存代码：

<profiles>
  <add extension=".js" policy="CacheUntilChange" kernelCachePolicy="DontCache" />
  <add extension=".css" policy="CacheUntilChange" kernelCachePolicy="DontCache" />
</profiles>

下面我把这两个配置项的细节、区别和配置时要考虑的点拆解清楚：

一、policy的具体含义 #

policy控制的是用户模式缓存，也就是IIS的应用程序池进程（w3wp.exe）层面的缓存。你用的CacheUntilChange策略意思是：只要目标文件（比如.js、.css）的内容没发生修改，这个缓存就一直有效，直到文件被更新时自动失效。除此之外，它还有其他可选值，比如CacheForTimePeriod（按你设定的固定时长缓存）、DontCache（完全不启用用户态缓存）等。

这个缓存是在用户态进程里运行的，处理请求时会先检查这里的缓存，相对灵活，能适配一些复杂的场景。

二、kernelCachePolicy的具体含义 #

kernelCachePolicy对应的是内核模式缓存，由Windows系统的HTTP.sys驱动直接管理，属于更底层的缓存机制。你设置的DontCache就是完全不启用内核缓存。它的可选策略和policy基本一致，比如同样支持CacheUntilChange、CacheForTimePeriod。

内核缓存的优势是性能极高——请求进来时不需要经过w3wp进程，直接由内核返回缓存内容，响应速度比用户态缓存快很多。

三、两者的核心区别 #

• 运行层级不同：policy在用户态（w3wp.exe进程），kernelCachePolicy在内核态（HTTP.sys驱动）
• 性能差异明显：内核缓存绕过了用户态进程的处理逻辑，性能远高于用户态缓存；用户态缓存虽然慢一点，但支持更复杂的缓存规则
• 适用场景不同：内核缓存只适合无身份验证、纯静态的资源；用户态缓存可以处理需要身份验证、动态生成的内容，甚至能和ASP.NET的缓存逻辑联动

四、配置时需要考虑的因素 #

• 资源类型：如果是纯静态资源（像你的js、css、图片），完全可以把kernelCachePolicy设为CacheUntilChange，大幅提升响应速度；但如果是动态页面（比如.aspx、.php）或者需要登录才能访问的资源，内核缓存就不适用了，只能用用户态缓存或者直接禁用
• 内容更新频率：如果资源经常变动，CacheUntilChange是最优选择，不用手动设置过期时间，文件一变缓存自动失效；如果资源是固定周期更新（比如每天凌晨更新），可以用CacheForTimePeriod设置对应的时长（比如duration="00:24:00"）
• 身份验证需求：如果资源需要用户登录才能访问，绝对不能开内核缓存——HTTP.sys无法识别用户身份，会把同一份缓存内容返回给所有用户，直接导致权限混乱
• 服务器资源限制：内核缓存占用的是系统级内存，大量启用可能影响服务器上其他进程的运行；用户态缓存占用的是应用程序池的内存，要注意应用池的内存配额，避免缓存过多导致进程回收
• IIS模式兼容性：IIS 7的集成模式和经典模式对缓存的支持有细微差别，比如经典模式下有些用户态缓存策略可能无法正常生效，配置前要确认你的应用程序池模式

内容的提问来源于stack exchange，提问作者Ali Sheikhpour