我有两个问题。由于它们彼此相关，因此我在一篇文章中询问它们。
1) 在 Django 应用程序中广泛使用会话是一种好习惯吗？我制作了一个测验应用程序，每个问题都是即时制作并存储在会话中的。当用户回答第一个问题时，会生成第二个问题并将其保存在与第一个问题相同的会话变量中，依此类推。我还使用会话来跟踪正确答案的数量、已回答的问题、下一个问题的 ID 以及其他一些变量。在我见过的所有 django 应用程序中，我的虽然很小，但却充满了 request.session。正常吗？或者你有什么更好的方法？
2) 由于这个应用程序都是基于会话的，如果我在同一个浏览器中打开一个新选项卡，并输入测验的 url，它将从另一个选项卡所在的位置开始。如何限制选项卡彼此看到？
谢谢
【问题讨论】：
1) 在 Django 应用中广泛使用会话是一种好习惯吗？
我认为您应该重新提出您的问题，以考虑会话的性质是否适合您想要实现的目标。了解 会话在 Django 中的工作方式。会话 ID 存储在 cookie 中，因此基本上会话的生命周期和行为直接受 cookie 的性质影响。
将自己置于不了解 Cookie 何时以及如何（或什至是否）被操纵的用户的脑海中。如果你最终得到“我不在乎系统是否因为某些抽象的技术原因（例如关闭我的浏览器、通过清除浏览器的历史记录和意外删除 cookie 等）手动重置”。那么这次会议是个不错的选择。
恕我直言，Django 使将问题存储在数据库中变得非常容易，我通常会在不问自己问题的情况下创建帐户和使用数据库。
2) 由于这个应用程序都是基于会话的，...我怎样才能限制标签彼此看到？
那么您不应该使用 Django 会话，因为它们是基于 cookie 的，而 cookie 是这种行为背后的真正罪魁祸首。由于这是一个测验类型的事情，我假设您在每一页上至少有一个表格。生成某种自定义会话 ID 并将其存储在隐藏的表单字段中。您也可以将其存储在查询字符串中，但这不是很“Django-ish”。
【讨论】：
如果您不需要会话提供的数据持久性，那么只使用会话是非常好的和正常的。这可能很明显，但如果您想保存与登录用户相关的结果、问题和答案，您至少需要深入研究 Django 的模型。
您始终可以使用 URL 参数（存储在 request.GET 中）来区分浏览器选项卡；如果在没有 URL 参数的情况下加载新页面，则生成一个随机值并重定向到 URL，并将随机值作为 URL 参数附加。使用 URL 参数值作为会话键结构的一部分来区分浏览器选项卡数据。
【讨论】：