因此，如果我对您的理解正确，则希望避免在控制器中使用大量这样的代码：
SomeModel.create({companyId: req.session.companyId, ...})SomeModel.find({companyId: req.session.companyId, ...})很公平。也许您担心
companyId将来会重命名，或者需要进一步处理。如果要使用自定义控制器操作，最简单的解决方案是为模型创建类方法，以将请求作为参数接受：
SomeModel.doCreate(req, ...);SomeModel.doFind(req, ...);
另一方面，如果您使用的是v0.10.x，并且可以将蓝图用于某些CRUD操作，则将受益于使用自己的代码覆盖蓝图的能力，因此所有创建和查找的内容都会自动使用在
companyId从会话。
如果您来自非节点背景，这可能会引起一些头疼。“为什么不让会议在任何地方都可以使用？” 你可能会问。“就像在PHP中一样！”
原因是PHP是 无状态的-
传入的每个请求本质上都是该应用程序的全新副本，而请求之间的内存没有共享。这意味着任何全局变量仅在单个请求的有效期内有效。这个奇妙的
$_SESSION哈希值是您和您自己的，一旦请求被处理，它就会消失。
将其与本质上在单个进程中运行的Node应用程序进行对比。您设置的所有全局变量都将在传入的每个请求之间共享，并且由于请求是异步处理的，因此无法保证一个请求会在另一个请求开始之前完成。这样的情况很容易发生：
- 请求A进入。
- Sails获取请求A的会话并将其存储在全局
$_SESSION
对象中。 - 请求A调用
SomeModel.find()
，它异步调用数据库 - 在数据库发挥作用的同时，请求A放弃了对Node线程的控制
- 请求B进入。
- Sails获取请求B的会话并将其存储在全局
$_SESSION
对象中。 - 请求B放弃对线程的控制以执行其他一些异步调用。
- 请求A返回其数据库调用的结果，并从
$_SESSION
对象中读取某些内容。
您可以在此处看到问题-
请求A现在具有错误的会话数据。这就是会话对象驻留在请求对象内的原因，以及为什么需要将其传递给想要使用它的任何代码的原因。太努力地避免这一点将不可避免地导致麻烦。
