读取javascript中cookie的值需通过解析document.cookie字符串实现，因为其返回的是类似"key1=value1; key2=value2"的格式，而非对象。1. 使用document.cookie获取所有cookie字符串；2. 通过分号分割成数组；3. 遍历每个项并去除前导空格；4. 检查是否以目标名称加等号开头，防止前缀误匹配；5. 找到后使用decodeuricomponent解码并返回值，否则返回null。常见问题包括：未解码导致乱码、httponly属性阻止js访问、secure属性限制仅https传输、路径或域不匹配导致无法读取。现代更推荐的方法有：1. 使用js-cookie等库简化操作；2. 用web storage api（localstorage/sessionstorage）替代cookie存储非自动发送的数据，提升性能和容量；3. 敏感数据由服务器端管理会话，客户端仅保存会话id，增强安全性。因此，尽管手动解析cookie繁琐，但理解其原理有助于正确处理各种边界情况，并选择更优的替代方案完成开发任务。
在JavaScript里要读取Cookie的值，核心就是利用
document.cookie这个属性。它会返回一个包含当前页面所有可访问Cookie的字符串，格式通常是
key1=value1; key2=value2; ...。所以，拿到这个大字符串后，你需要做一些字符串处理，才能从中提取出你想要的那个特定Cookie的值。这听起来可能有点绕，但实际操作起来，就是一些基本的字符串分割和查找。
要读取一个特定名称的Cookie，你可以这样做：
function getCookie(name) {
// 加上等号，确保匹配的是完整的Cookie名称，而不是前缀
const nameEQ = name + "=";
// 获取所有Cookie，并按分号和空格分割成数组
const ca = document.cookie.split(';');
for (let i = 0; i < ca.length; i++) {
let c = ca[i];
// 移除字符串开头的空格，有些浏览器会加
while (c.charAt(0) === ' ') {
c = c.substring(1, c.length);
}
// 如果找到指定名称的Cookie
if (c.indexOf(nameEQ) === 0) {
// 返回解码后的Cookie值
return decodeURIComponent(c.substring(nameEQ.length, c.length));
}
}
return null; // 如果没有找到，返回null
}
// 示例用法：
// 假设有一个名为 'user_token' 的Cookie
// const userToken = getCookie('user_token');
// if (userToken) {
// console.log('用户令牌是:', userToken);
// } else {
// console.log('未找到用户令牌。');
// }
为什么直接使用 document.cookie
看起来那么麻烦？
这确实是很多初学者会疑惑的地方。
document.cookie设计之初，可能更多是作为一个低层级的接口，直接暴露浏览器存储Cookie的原始字符串。它返回的不是一个方便操作的JavaScript对象，而是一个单一的、由分号分隔的键值对字符串。这就像你走进一个图书馆，不是直接告诉你哪本书在哪，而是给了你一张长长的、列满了所有书名和编号的清单，并且这些清单项之间用逗号隔开，你得自己去扫描、去匹配。
这种设计有它的历史原因，也反映了Cookie本身作为HTTP头部信息的一种简单传输机制。它不关心你如何解析，只负责把数据打包好送过来。所以，你需要手动去解析这个字符串，提取出你真正需要的那部分信息。比如，你可能要处理编码问题（因为Cookie的值可能会包含特殊字符，需要被编码），还要确保你匹配的是整个Cookie名称，而不是某个Cookie名称的前缀。这种“原始”性，虽然增加了我们的工作量，但也给了我们极大的灵活性去处理各种复杂的Cookie场景，尽管大多数时候我们只是想简单地取个值。
读取Cookie时可能遇到哪些常见问题或陷阱？
在处理
document.cookie时，确实有一些坑需要注意，否则很容易踩雷：
一个常见的问题是编码。Cookie的值可能会包含一些非ASCII字符，比如中文、空格或者其他特殊符号。这些字符在存储到Cookie时通常会被
encodeURIComponent编码，所以你在读取它们的时候，也需要用
decodeURIComponent来解码，才能得到原始的、可读的值。如果忘记解码，你拿到的可能就是一串乱码，或者带百分号的编码字符串。
里面有2个文件夹。其中这个文件名是:finishing，是我项目还没有请求后台的数据的模拟写法。请求后台数据之后，瀑布流的js有一点点变化，放在文件名是：finished。变化在于需要穿参数到后台，和填充的内容都用后台的数据填充。看自己项目需求来。由于chrome模拟器是不允许读取本地文件json的，所以如果你要进行测试，在hbuilder打开项目就可以看到效果啦，或者是火狐浏览器。
再来就是HttpOnly
和Secure
属性。这俩是Cookie的安全属性。如果一个Cookie被设置为
HttpOnly，那么它就完全无法通过JavaScript来访问，
document.cookie根本就不会包含它。这是为了防止跨站脚本（XSS）攻击，即使攻击者成功注入了恶意JS代码，也无法窃取到这些敏感的Cookie信息。而
Secure属性则表示这个Cookie只能通过HTTPS连接发送。你在HTTP页面上尝试读取一个
SecureCookie，即便它存在，
document.cookie也可能不会显示它（或者说，它根本就不会被发送到非HTTPS的页面）。所以，如果你发现某个Cookie死活读不到，不妨检查一下它的
HttpOnly和
Secure标记。
还有一点，Cookie的路径（Path）和域（Domain）。Cookie是有作用域的。一个Cookie可能只对特定的路径或子域有效。比如，一个设置了
Path=/app的Cookie，在
/路径下是读不到的。同样，如果Cookie的域是
example.com，你在
sub.example.com上可能也读不到，除非它的域被设置成了
.example.com（表示对所有子域都有效）。这意味着，你当前页面的URL必须在Cookie的作用域范围内，才能成功访问到它。
除了手动解析，有没有更现代或更推荐的Cookie管理方式？
当然有。虽然手动解析
document.cookie是基础，但在实际项目中，我们通常会寻求更优雅、更健壮的解决方案。
首先，使用成熟的JavaScript库是一个非常推荐的做法。比如
js-cookie就是一个非常流行的轻量级库。它把所有Cookie的读写、删除操作都封装得很好，你只需要调用像
Cookies.get('my_cookie_name')这样的简单API，就不用关心背后的字符串解析、编码解码、路径域等复杂细节了。这些库通常也考虑了各种浏览器兼容性问题和一些边缘情况，用起来省心省力，代码也更清晰。
其次，对于一些不一定需要随HTTP请求自动发送的数据，或者需要存储大量数据的情况，Web Storage API（localStorage
和sessionStorage
）是更好的选择。它们提供了键值对的存储方式，API非常直观，比如
localStorage.setItem('key', 'value')和localStorage.getItem('key')。它们的主要区别在于：localStorage是持久化的，即使浏览器关闭数据也还在；
sessionStorage则只在当前会话有效，浏览器一关数据就没了。它们最大的优势是容量比Cookie大得多（通常5MB到10MB），而且不会在每次HTTP请求时都带上，减轻了网络负担。但缺点是它们不能像Cookie那样自动在客户端和服务器之间传递，需要手动通过Ajax等方式发送。
最后，如果你的应用对Cookie的依赖非常重，或者需要更复杂的会话管理，那么服务器端管理Cookie会是一个更安全、更可靠的方案。客户端只负责传递一个会话ID，真正的用户数据、权限信息都存储在服务器端。这样，即使客户端的Cookie被窃取，攻击者也只能拿到一个ID，而无法直接获取敏感数据。服务器端可以对会话进行更精细的控制，比如强制过期、吊销会话等。这并不是说客户端就完全不处理Cookie了，而是说对于关键业务逻辑和数据，服务器端承担了主要责任，客户端只是一个辅助的角色。
