企业官网建设流程全解析

1. 先说我怎么被这个登录问题卡住的

前段时间想在 VS Code 里装个 LeetCode 插件，图的是本地写题、离线翻历史提交、顺便用自己熟悉的编辑器键位，省得每次都开网页。装好插件之后，按下登录按钮，弹出的不是账号密码输入框，而是一段提示——让我去浏览器登录后复制 cookie 粘进来。

我当时第一反应是：不至于吧，都 2025 年了还要手动喂 cookie？

结果照着平时“登录失败就重新登录”的思路试了好几遍，发现这插件压根不走 OAuth 那套流程，只认 cookie。更尴尬的是，我第一次随手从浏览器复制了一整串 cookie 粘进去，插件显示登录成功，但一提交代码就报错，要么提示会话无效，要么直接弹出“请重新登录”。折腾了半小时，才搞清楚原来 cookie 不是“有就行”，得拿到对的、新鲜的、完整的会话 cookie才行。

这篇其实就是个备忘，把这次从“卡在登录”到“稳定跑通”的完整过程记下来，包括 cookie 到底要怎么找、怎么判断有没有拿对、过期之后怎么快速更换，以及几个特别容易踩的坑。如果你是刚开始用 LeetCode 插件、或者装上之后卡在登录这一步，这篇应该能帮你少走不少弯路。

2. cookie 登录到底是怎么回事，为什么插件不直接用密码

先理清一件事：LeetCode 类插件（包括 VS Code 生态里最常用的那几款，以及一些命令行刷题工具）为什么普遍采用 cookie 登录，而不是像普通网站那样输入账号密码。

2.1 插件想要的是“登录状态”，而不是口令

网站的身份认证一般分两类思路。

一类是传统表单登录：客户端把用户名密码发给服务器，服务器校验后返回一个 token，后续请求都带这个 token。这种方式对纯网页很自然，因为登录页、校验逻辑、跳转流程全都是网页端自己的事，插件只要模拟表单提交也能做，但问题在于 LeetCode 的前端登录流程里掺了验证码、多步跳转、可能的异地风控校验，插件作者要维护这套适配成本很高，而且网站改版一次就崩一次。

另一类就是 cookie 会话：你先在浏览器里完成一次人工登录，浏览器会存下一批用于标识会话的 cookie。插件要做的事很简单——把这份 cookie 原样带进自己的请求里，服务器就会认为“这是同一个已登录的浏览器”。这种方式对插件来说实现成本极低，稳定性也高，代价就是：cookie 这东西会过期，而且不能跨设备随便用。

所以不是插件开发者懒，而是他们选了一条更稳的路。谁都希望输一次密码就永久生效，但现实是 LeetCode 官方接口并不给第三方工具提供长期凭证，cookie 成了最通用的折中方案。

2.2 这些 cookie 里到底有什么

正常登录 LeetCode 网站后，浏览器里至少会存下这么几类关键的 cookie：

对插件来说，LEETCODE_SESSION 是最关键的，它是服务端签发的会话标识，请求时带上它，服务器才会把你的请求识别为“已登录用户”。拿不到这个值，就算你复制了几十个其他 cookie 也无济于事。

2.3 为什么很多人第一次复制就失败

我后来复盘发现，第一次失败的核心原因是：我复制的是浏览器里“当前全部 cookie”，但其中混入了大量无关的埋点 cookie，而且有些 cookie 的 Path、Domain 属性跟 LeetCode API 请求并不完全匹配。插件拿到这串“大杂烩”后，请求发出时到底带哪些 cookie，取决于它内部对 cookie 字符串的解析方式。不同插件处理差异很大，有的直接原样塞进请求头，有的会做一轮筛选。一旦筛选逻辑和网站要求的匹配不上，就会出现“界面显示已登录、但一请求就 401”的诡异情况。

更稳妥的做法是：只挑必要的会话 cookie 拼成一段精简字符串，而不是无脑全选。后面我会具体说怎么挑。

3. 从浏览器里拿到一份“插件能认”的 cookie

这一步是整个流程的核心。操作本身不复杂，但有几个细节容易被忽略，拿错了后面全白搭。

3.1 准备干净的登录环境

建议用你平时常用的浏览器（Chrome、Edge、Firefox 都行），开一个普通窗口访问 leetcode.com，先确保自己已经点了登录按钮、能看到右上角自己的头像。这里有个容易踩的坑：如果你用的是浏览器的“无痕模式”，登录状态会随着窗口关闭被清空，复制到的 cookie 也就只能活一小会儿，不建议从这个模式里复制。

登录成功后，按 F12 打开开发者工具，切到 Network（网络）面板。刷新一次页面，然后在请求列表里随便点一个接口请求，往下找 Request Headers 里的 Cookie 字段。这一步是为了拿到“实际用于 API 请求”的 cookie，而不是开发者工具里 Application 面板下按域名整理出来的静态 cookie——后者往往包含了更多插件用不到的东西。

3.2 从请求头里复制最可靠

以 Network 面板为例，操作顺序是这样的：

1. 登录 leetcode.com，确认右上角显示你的头像。
2. 按 F12 打开 DevTools，切到 Network 标签。
3. 刷新页面，在筛选框里输入api或直接找名为graphql的请求（LeetCode 的前端绝大多数数据请求走的是这个接口）。
4. 点开任意一个请求，在 Headers 标签下找到 Request Headers 里的Cookie:一行。
5. 右键 → Copy value，把这一整段 cookie 字符串复制下来。

这段字符串里就包含了服务器在正常请求时会收到的完整 cookie 集合，是最接近“插件需要内容”的原始素材。如果你看到的 Cookie 值很长（上百个字符甚至更长），这很正常，别觉得奇怪，也别手动删减，先整段复制下来再说。

对比之下，从 Application 面板里手动勾选复制的方式不仅繁琐，而且很容易多选或少选，导致插件解析后得到的 cookie 集合和正常请求不一致。整段复制，从源头上规避了这种偏差。

3.3 用 cookie 字符串组一段“精简版”

整段复制完成后，我会建议你再手动精简一下。理由很实际：全量 cookie 里除了会话凭证，还有大量 _ga、_gid、_gat 之类统计埋点，不带它们对登录状态毫无影响。真正对插件有效的，一般也就是LEETCODE_SESSION和可能涉及的cf_clearance。

手工精简的步骤也不麻烦：

• 把复制到的 cookie 字符串按分号拆开，形如k1=v1; k2=v2; k3=v3。
• 把包含LEETCODE_SESSION的那一段单独留下来。
• 如果请求头里能看到cf_clearance或__cf_bm，也一并留下。
• 再检查一下是否还有csrftoken之类的键，有就留下。
• 其余的全删，然后把留下的部分用;重新拼接。

这个过程看似手动，其实非常值。精简过后的 cookie 字符串不仅短小，而且在插件里定位问题时要容易得多——一旦请求失败，你能立刻确认是不是LEETCODE_SESSION本身的问题，而不是被一堆无关 cookie 干扰了排查。

3.4 一个小提醒：cookie 的时效比你想象中短

LeetCode 的会话 cookie 并不是永久有效的。实测下来，长的话能顶一两周，短的话可能两三天就失效，中间只要有一次异地登录、退出登录、修改密码的操作，cookie 基本立刻作废。所以如果你发现插件前一天还能用、后一天突然就 401 了，别怀疑是自己配置有问题，大概率就是会话过期了。

拿到 cookie 之后赶紧配置到插件里，别放记事本里吃灰。配置步骤见下一节。

4. 在编辑器插件里把 cookie 配置上去

不同编辑器对应的 LeetCode 插件操作入口不太一样，但核心逻辑一致：告诉插件“用这份 cookie 作为身份凭证”。我这里以 VS Code 里最常用的插件为例说明。

4.1 找到插件设置入口

VS Code 里安装 LeetCode 插件之后，左下角或者活动栏会出现 LeetCode 的图标。点击图标，通常能看到一个登录入口，常见的有：

• 命令面板（Ctrl+Shift+P）→ 输入LeetCode: Sign In；
• 左侧 LeetCode 面板顶部的账户区域，点击后选择登录方式。

插件一般会提供两种登录方式：一种是通过浏览器直接登录（适合原来没配置过任何东西的新用户），另一种就是“使用 cookie 登录”或“手动输入 token”。选后者，然后会弹出输入框，把上一节复制到的 cookie 字符串粘贴进去，回车即可。

4.2 配置项级别：把 cookie 写进 settings.json

也有一部分场景下，插件不会弹出输入框，而是要求你去改配置文件。VS Code 里通过Ctrl+Shift+P打开设置（JSON），可以搜索配置项。以常见字段为例，插件会有一个专门的 key 用来存放 cookie 字符串，类似这样：

{ "leetcode.cookie": "LEETCODE_SESSION=xxxxx; csrftoken=xxxxx;" }

具体 key 名称以你安装插件的文档为准，不同插件差异很大，有的叫cookie，有的叫session，还有的干脆是leetcode.session之类的深层路径。

值得注意的是：现在不少插件改用了leetcode.session走本地文件方式（具体路径可能因版本而异）。老版本存配置文件，新版本接口改了，如果你照着旧教程改完没生效，先看看自己装的插件版本和教程是不是同一个时代。

4.3 配置完成后怎么验证真的登录上了

粘贴 cookie 但不做验证，等于蒙眼开车。保存配置后先别急着刷题，按下面的顺序自查一遍：

1. 重新加载窗口（Ctrl+Shift+P→Developer: Reload Window）。
2. 打开 LeetCode 面板，看右上角或顶部是不是出现了你的用户名。
3. 随便打开一道题目，看题面是否能加载出来。
4. 如果题面能加载，再打开“每日一题”或“题库列表”，确认列表能正常拉取。

这一步的意义在于，把“看起来登录了”和“真正能拉接口数据”区分开。很多插件在 cookie 无效时依然会显示“已登录”的假象——因为它在界面上只是记录了你粘贴过 cookie 这个动作，而真实的服务端校验要等到第一次请求时才发生。题面能加载出来，才是真正验证成功。

5. 实测中的三个坑：真的会把人气笑

配置过程本身不复杂，但实际操作中你会遇到各种让人摸不着头脑的状况。我把这次实测中踩到的三个典型问题都记了下来，每个都有明确的特征和处理方式。

5.1 提交代码时报 401 或 “请先登录”

这个是我遇到的最典型的坑。现象是：题面能加载、列表能刷新、你甚至能写代码跑测试用例，但一提交就报 401 或者提示会话无效。

排查步骤很固定：

• 先重新复制一次 cookie，大概率是旧的会话密钥已经过期了；
• 如果重试无效，检查你的 cookie 字符串里是不是少了LEETCODE_SESSION这一段；
• 再看看 cookie 字符串里有没有混入空格、换行符——从浏览器复制的时候很容易把一段换行带到剪贴板里，粘贴时看着没问题，实际却让 Cookie 头解析失败。

有一个小技巧：复制完成后，先在记事本里看一眼字符串首尾有没有多余字符。别嫌麻烦，这个步骤能帮你过滤掉一大半低级错误。

5.2 cookie 看起来是正确的，但首页列表加载缓慢或失败

另一种情况是：粘了 cookie，登录状态也显示了，但 LeetCode 面板一直转圈，题解列表加载不出来，刷新也没有反应。

这个问题的成因往往在于 Cloudflare 的校验。LeetCode 的接口前面有一层风控，当你请求过于频繁或请求特征与正常浏览器差异太大时，会被中间层拦截。插件请求带了你的 cookie 也只是“身份正确”，但请求头里缺少浏览器特有的 User-Agent、Accept-Language 等完整特征，还是可能被拦。

处理思路有两个方向：

1. 不要让插件频繁刷新题库，每次操作间隔几秒，别像爬虫一样短时间内刷几百下；
2. 如果持续不行，换个网络环境（比如从 Wi-Fi 切到手机热点）再试一次。

这种情况和 cookie 本身无关，纯粹是请求频率与特征问题。插件做得比较糙，遇到这种问题通常只能等风控策略解除，或者换个时间段再试。

5.3 登录成功，但换了台电脑 cookie 就不能用了

这是很多人忽略的一点：cookie 是和浏览器会话绑定的，它有“属地”概念。你在 A 电脑的浏览器上登录得到的 cookie，换到 B 电脑的插件里去使用，绝大多数情况下会立刻失效——LeetCode 的服务端会做基本的设备指纹校验，session 换设备后不再被信任。

所以别想着“在公司电脑上登录一次，回家直接复用 cookie”。这种方案我就是没试过，试过的朋友普遍反馈直接失败。正确做法就是在哪台电脑用，就在哪台电脑浏览器上重新登录一次、拿一次 cookie，虽然费点事，但这是最稳定的。

5.4 一个小问题：插件和浏览器 cookie 的“新鲜度”不一致

还有一个容易让人困惑的点：浏览器一直开着没关，在浏览器里 LeetCode 明明还是登录状态，但插件的 cookie 却失效了。

原因是：网站服务端在会话持续过程中会不定期轮换/续签 session，但浏览器里存的 cookie 会跟着每次请求自动更新，而你在插件里粘贴的是“某一时刻的旧值”。如果那一时刻之后服务端做了会话变更，你粘的旧值自然就失效了。所以，不要拿浏览器当前的登录状态去判断插件里的 cookie 是否还有效，要以插件实际请求结果为准。

如果你发现浏览器一直能访问、但插件经常失效，大概率不是网站的锅，而是因为你粘贴的是一份快照，快照总有陈旧的时候。解决办法只有一条：失效就重新复制一次，养成习惯。

6. 一些事后反思：从“cookie 登录”延伸到其他工具

这次折腾的不只是 LeetCode 插件本身。cookie 登录这个模式，在很多工具链里都出现过，而且踩坑逻辑惊人相似。

6.1 类似的场景无处不在

命令行刷题工具、某些 API 调试工具、甚至一些自动化脚本，都有“从浏览器复制 cookie 去配置”的操作。原理都一样——工具不想重造登录轮子，就绕道借浏览器的登录态。你只要理解“cookie 是会话凭证、会过期、有设备指纹绑定”这几个基本点，就能应对绝大多数这类工具的问题。

比如有的工具要求提供Cookie: xxx请求头，有的工具要求填LEETCODE_SESSION单值，还有的工具提供的是“扫码登录”但背后仍然要你手动配置一次 cookie。每次遇到这种需求，我都习惯先问自己三个问题：

• 这个工具要的 cookie 是“完整请求头级别”的还是“单键值级别”的？
• 它的请求会不会被风控拦截？如果会，我该怎么降低请求频率？
• 如果 cookie 失效了，我重新获取的路径是否顺畅？

把这三个问题想清楚，基本就没什么坑了。

6.2 换个思路：哪些情况下可以彻底绕开 cookie

如果你经常被 cookie 过期折腾，其实还有一些替代方案值得考虑：

• 直接用网页版刷题：最省心，没有任何配置问题，缺点是没有本地个性化环境；
• 用支持账号密码登录的第三方客户端：选择越来越少，且不稳定，因为网站侧随时可能调整登录流程；
• 自己包一层带登录态的代理服务：适合有技术能力的场景，比如写一个小服务专门维护会话、定期续期 cookie，然后让插件走你的代理。这种方式能根治问题，就是成本偏高。

对于大多数人来说，老老实实复制 cookie、过期了就重新复制，反而是性价比最高的路径。尤其是只刷题、不搞自动化的人，多花两分钟重新配置一次，比研究各种绕开方案要省事得多。

说到这，这篇备忘也就把我的完整过程记录下来了：为什么会卡在 cookie 登录、cookie 里真正起作用的是什么、怎么从浏览器拿到一份可靠的 cookie、怎么配置到插件里、以及后续失效时最有可能踩的坑和排查顺序。希望这些内容对跟我一样在这上面折腾过的人有些帮助，哪怕只是让你少走一次弯路，也算这篇备忘值了。