我想知道何时选中return nil复选框错误，
在Best practices之后，有些情况下不应该使用Cache编译的脚本，但是不使用Cache compiled script if available的示例是错误的，我做了一个测试，它所采用的值是更新的值${varName}而不是第一个值。
使用JSR 223元素时，建议检查Cache编译 脚本，如果可用属性，以确保脚本编译是 如果基础语言支持它，则缓存。在这种情况下，请确保 脚本不使用$ {varName}作为缓存的任何变量 只取$ {varName}的第一个值。
有人知道真实案例使用缓存是错误的吗？
修改
我在脚本中使用$ {varName}进行检查，并且在使用/不使用缓存时有类似的结果：
我在Jmeter中定义名为${varName}的变量值为1，并创建了一个脚本：
aa在复选框的两种情况下都返回值1，因此它与缓存无关
还尝试使用Beanshell（没有编译语言，没有def aa =“2”;）并得到相同的结果。
答案 0 :(得分：1)
文档的含义是，只要$ {varName}具有不同的值，新条目就会存储在缓存中，最终将填充无用的数据。
所以在这种情况下它是错误的，$ {varName}应该替换为
vars.get（ “varName中”）
事实上，如果您使用正确的JMeter语法，我没有看到取消选中此选项的真正原因
由于上述风险以及“非共识”原因，默认情况下，该选项未经选中：
至于性能，它是否完全相同，你检查它是否支持不支持编译的语言，因为JMeter做的第一件事就是在使用复选框之前检查“supportsCompilable”，参见：
答案 1 :(得分：0)
如果使用的脚本引擎在编译脚本时不支持缓存，则不应使用缓存。由于只有Groovy能够编译脚本，所以你应该在Groovy的这个框中打勾并为其他引擎取消注释（每次调用脚本时都会触发没有意义的代码块）
Well-behaved Groovy engine should：
将JMeter函数和变量内联到脚本中对于任何语言来说都有点危险，因为它可能会导致编译失败，甚至更糟糕的导致您不期望的代码。如果Groovy JMeter变量语法与Groovy GString template
冲突因此，内联变量将导致每次调用脚本时重新编译脚本的开销。
因此，请继续关注JMeter的最佳实践，并记住一个小小的提示：尽可能避免编写脚本，因为没有脚本选项的性能与Java一样快，请查看Beanshell vs JSR223 vs Java JMeter Scripting: The Performance-Off You've Been Waiting For!指南以获取详细信息。