Answers:
答案是肯定的：
会话在服务器端维护。就服务器而言，AJAX请求和常规页面请求之间没有区别。它们都是HTTP请求，并且都以相同的方式在标头中包含cookie信息。
无论是常规请求还是AJAX请求，都将从客户端将相同的Cookie始终发送到服务器。Javascript代码不需要做任何特殊的事情，甚至不需要了解这种情况，它的工作原理与常规请求相同。
Warning: session_write_close(): Failed to write session data (user)最近在项目中间歇性地收到一个错误，但仅在页面其余部分的加载期间发生AJAX请求时才出现。我正在使用MySQL数据库存储会话数据，并且主页请求可能锁定了该表，从而阻止了AJAX请求对其进行访问。
您真正要了解的是：cookie是否随AJAX请求一起发送？假设AJAX请求针对同一个域（或在cookie的域约束内），则答案为是。因此，返回给同一服务器的AJAX请求确实保留了相同的会话信息（假设被调用的脚本与希望访问会话信息的任何其他PHP脚本一样发出一个session_start（））。
好吧，并非总是如此。使用cookie，您感觉很好。但是“我可以安全地依赖于存在的id”敦促我扩大讨论的重点（主要是供参考，因为此页面的访问者数量似乎很高）。
可以将PHP配置为通过URL重写而不是cookie来维护会话。（它的好坏（<-参见此处的最高注释）是一个单独的问题，让我们继续讨论当前的问题，仅附带一个注解：基于URL的会话最突出的问题-公然裸会话ID的可见性-内部Ajax调用不是问题；但是，如果为Ajax启用了该功能，那么其余站点也已启用了该功能，因此...）
在进行URL重写（无cookie）会话的情况下，Ajax调用必须自己处理好它们的请求URL。（或者，您可以推出自己的自定义解决方案。在要求不高的情况下，您甚至可以求助于在客户端维护会话。）重点是，如果不使用cookie，则会话连续性需要明确的注意：
如果Ajax调用只是从HTML中逐字提取 URL（从PHP接收），那应该可以，因为它们已经被煮熟了（嗯，煮熟了）。
如果他们需要自己组装请求URI，则需要将会话ID手动添加到URL。（检查此处，或PHP生成的页面源（启用URL重写），以了解如何执行此操作。）
来自OWASP.org：
有效地，如果满足某些条件（例如，存在不支持Cookie的Web客户端或不支持Cookie的情况），则Web应用程序可以同时使用Cookie，URL参数或机制，甚至可以从一种切换到另一种（自动URL重写）。由于用户隐私问题而被接受）。
在Ruby论坛中：
当使用带有cookie的php时，即使对于Ajax XMLHttpRequests，会话ID也会自动在请求标头中发送。 如果使用或允许基于URL的php会话，则必须将会话ID添加到每个Ajax请求url。
AJAX请求保留会话非常重要。最简单的例子是，当您尝试对管理面板进行AJAX请求时，可以说。当然，您将保护您向其发出请求的页面，而不被管理员登录后没有会话的其他人访问。说得通？
将您的session（）auth放在接受ajax请求的所有服务器端页面中：
if(require_once("auth.php")) {
//run json code
}
// do nothing otherwise那是我做过的唯一方法。
HttpOnly在设置cookie时设置一个标志，这意味着您的Javascript将无法看到该cookie。然而该cookie 将仍然是这两个AJAX和普通页面请求被发送，并继续工作完全一样。您的Javascript不会在中显示document.cookie。