Platform Cache — Best Practices

今天我们来聊聊在Salesforce里使用平台缓存的一些最佳做法，这些技巧能让你的代码跑得更快、更稳。 首先，衡量性能一定要用`System.currentTimeMillis()`，前后打时间戳。别凭感觉，数字才最诚实。 接着，处理缓存未命中时最好利用Cache Builder模式。也就是在`get`的时候，如果发现缓存里没有，不是粗暴地返回null，而是用`Cache.CacheBuilder`接口去自动构建并存入缓存，这样逻辑更清晰，还能把同一类key的构建请求自动分组，避免重复计算。 说到分组，用`get(键)`方法时，同一个分区里的相同key的请求会被平台自动合并，只构建一次，这在高并发下特别重要。所以设计key的时候要有意识地去利用这个特性。 缓存项目的大小也有讲究：少存几个大的，比存一堆零碎的小项要好。你可以把相关记录包装成一个列表或一个Apex类，然后一次性缓存。这样能减少`get`调用的次数，开销更小。 但别忘了平台的限制：单个缓存项不能超过100KB，会话缓存整个分区最多500KB，组织缓存最多1,000KB。规划缓存时要留个心眼，别超了。 诊断页面确实方便，但调用它非常昂贵，生产环境里千万别随便在代码里触发，只在真正排查问题时谨慎使用。 类似地，`getKeys()`和`getCapacity()`这类查询方法也比较重，尽量少用。如果要判断一个键存不存在，千万别先`contains()`再`get()`，这样会多一次往返。直接`get()`，然后判断返回值是不是null就好，既简单又省资源。 最后，清除缓存要克制，只在数据真的变了、必须刷新时才调用`remove`或者`clear`。不要为了“保险”而动不动清空整个缓存。 我举个反例加深印象：如果你有一个列表要缓存，千万别在循环里一条一条地`put`。正确做法是把整个列表一次性`put`进去，这样是一次大的写入，比上百次小写入高效得多，也符合“缓存更大项目”的原则。 记住这些要点，你的缓存代码就能又快又稳，给用户流畅的体验。好，这节课就到这里。