因此，如果我对您的理解正确，则希望避免在控制器中使用大量这样的代码：

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应用程序进行对比。您设置的所有全局变量都将在传入的每个请求之间共享，并且由于请求是异步处理的，因此无法保证一个请求会在另一个请求开始之前完成。这样的情况很容易发生：

1. 请求A进入。
2. Sails获取请求A的会话并将其存储在全局$_SESSION对象中。
3. 请求A调用SomeModel.find()，它异步调用数据库
4. 在数据库发挥作用的同时，请求A放弃了对Node线程的控制
5. 请求B进入。
6. Sails获取请求B的会话并将其存储在全局$_SESSION对象中。
7. 请求B放弃对线程的控制以执行其他一些异步调用。
8. 请求A返回其数据库调用的结果，并从$_SESSION对象中读取某些内容。

您可以在此处看到问题-
请求A现在具有错误的会话数据。这就是会话对象驻留在请求对象内的原因，以及为什么需要将其传递给想要使用它的任何代码的原因。太努力地避免这一点将不可避免地导致麻烦。