Specs2在处理Acceptance规范时提升功能风格（如果需要，甚至是Unit规范）。
规范Specs2 philosophy中提到了使用旧样式（可变样式）的风险，并关注潜在的不良副作用：
要知道的重要事项是：
副作用仅用于构建规范片段 变异变量它们也用于短路执行 一旦失败（通过抛出异常）的例子。 如果您在示例的主体中构建片段或执行相同的操作 同时规范，天空应该倒下。 “上下文” 管理是用案例类或特征来完成的（见 org.specs2.examples.MutableSpec）
我不知道如何同时运行相同的规范，因为每个规范都与其他规范（分离的类的实例）不同，即使我们同时运行两次或更多次。
确实，specFragments（可变变量）：
protected[mutable] var specFragments: Fragments = new Fragments()
在名为a trait的{{1}}中声明，而不是FragmentBuilder（在scala sense =＆gt;单例中）或其他共享内容...，因此object是每个specFragments实例的局部变量。
那么一个场景可能会冒并发机制的风险呢？
我并没有真正弄清楚真实场景（非愚蠢）证明了Specs2功能风格的好处。
答案 0 :(得分：5)
可变规范的问题只能在构建规范时看到，而不是在执行时才能看到。在构建可变规范时，很容易产生意外的副作用
import org.specs2._
val spec = new mutable.Specification {
"example" >> ok
}
import spec._
def addTitle {
// WHOOPS, forgot to remove this line!
// test, add also an example
"this is only for testing" >> ok
"new title".title
}
addTitle
输出是：
new title
+ example
+ this is only for testing
Total for specification new title
Finished in 0 ms
2 examples, 0 failure, 0 error
所以，你是对的，指南中突出显示的句子（“同时执行相同的规范”）是不明确的。如果几个线程正在构建相同的规范对象，那么规范本身的构造可能是不安全的，但如果它们正在运行它，则它可能是不安全的（整个过程在该句子中称为“执行”）。
你的另一个问题是：“功能风格”有什么好处？从用户的角度来看，主要的好处是它是另一种写作规范，其中所有文本都是第一个，所有代码都放在其他地方。
总之，如果你愿意，不要害怕规范的可变风格！