快手与抖音 Cookie 获取和使用差异：导入成功，为什么还没登录？

把抖音账号管理流程适配到快手时，最初的现象有些迷惑：浏览器能启动，Cookie 能解析、注入，推荐页也正常打开，但侧栏仍然显示“立即登录”。

继续检查才发现，复制的是快手创作者服务平台的 Cookie，自动化打开的却是快手主站。更换为主站正常登录后的 Cookie，用户反馈“可以登录”。

这个过程提醒我，迁移账号管理功能时，不能只替换域名和选择器。Cookie 被浏览器接受、目标业务识别为登录、程序读到正确账号，是三步不同的验证。

本文整理自 2026 年 10 月 20 日的适配记录，项目实现分别对应 dyDM c27c2d0 与 ksDM a96b329。下文讨论正常登录后的本机自动化与会话复用，示例不包含真实凭据；登录成功来自当日用户反馈，资料读取、账号保存和跨重启复用仍需单独验收。

原来 dyDM 的使用指南推荐在同一网络环境下，登录抖音创作者中心，然后从开发者工具复制请求 Cookie。

沿用这套操作习惯，第一次快手样本取自 cp.kuaishou.com。但 ksDM 的目标页面是：

1	https://www.kuaishou.com/new-reco

创作者服务平台与推荐主站属于不同的业务入口。它们可能有登录关联，也可能使用不同的业务凭据；实际能否恢复登录，需要在目标页面验证。

两次样本中，与辨别来源有关的字段如下。这里仅列字段名和产品标记，没有令牌值：

观察项	此次失败样本	此次成功样本
复制来源	快手创作者服务平台	快手主站登录后的请求
业务字段	`kuaishou.web.cp.api_st`、`kuaishou.web.cp.api_ph`	`kuaishou.server.webday7_st`、`kuaishou.server.webday7_ph`
产品标记	`kwpsecproductname=onvideo-cp`	`kwpsecproductname=kuaishou-vision`
目标主站结果	仍显示“立即登录”	用户反馈可以登录

这些字段帮助定位了本次样本的区别，不是官方公布的完整必填清单。不能只留下表中的两个字段就保证登录，也不能因为名称里有 day7，就断言会话一定有效七天。

这次也没有重新独立测试抖音所有子站之间的登录关系。因此，dyDM 原指南的做法不能推导成“抖音的创作者平台 Cookie 在所有场景都适用于主站”。

HTTP 200，没有替页面完成登录验证

排查快手旧样本时，观察到当时前端使用 /rest/v/profile/get 获取当前账号状态。请求返回 HTTP 200，响应体却是：

1	{"result": 109}

同时，页面仍有可见的 .sidebar-login-button，显示“立即登录”，没有进入当前账号状态。

这里可以确定的是：该样本未能在目标主站恢复登录。HTTP 200 只说明请求返回了正常的 HTTP 响应，不等于账号业务验证通过。109 与本次未登录现象同时出现，但材料不足以将它解释为所有快手业务中固定的“Cookie 已过期”错误码。

如果只在 add_cookies() 没有报错时就提示“登录成功”，这个问题就会被藏起来。注入接口负责把数据放进浏览器，不替目标服务判断凭据是否有效。参数与作用范围可查 Playwright add_cookies 文档。

Cookie 导入、业务登录与当前账号身份是三个独立检查步骤

更换主站 Cookie 后的成功反馈覆盖“可以登录”。它还不代表昵称、快手号、统计读取、保存账号和重启后的会话复用已经全部通过线上验证。

排查主站登录时，先在正常浏览器中确认自己已经登录目标主站，再复制它实际发送的账号请求。这样能减少从不相关业务中取到凭据的可能。

快手：本次成功的获取路径

在 Chrome 中打开快手推荐页，正常登录，确认页面显示当前账号。
按 F12 打开开发者工具，进入 Network，刷新页面。
本次可以筛选 /rest/v/profile/get，确认请求来自目标主站。
打开请求的 Headers → Request Headers，复制完整的 Cookie 值。
在 ksDM 中导入并验证，从当前账号入口进入自己的主页，核对昵称和快手号后再保存。

接口路径是当日观察结果，不是长期稳定的公开接入协议。页面改版后，应寻找当前页面实际发起的账号状态请求，而不是机械等待旧路径。

抖音：把既有操作说明与目标验证分开

dyDM 原指南的入口是抖音创作者中心，这是已有项目说明。若排查的是主站自动化问题，可以先在 www.douyin.com 确认登录，进入自己的主页，在 Network 中选择主站与当前账号状态有关的请求，再复制其请求 Cookie，交给 dyDM 验证昵称和抖音号。

不要将“随便选一条请求”当作通用获取方法：图片 CDN、第三方统计或其他业务请求，可能没有携带目标页面需要的登录凭据。创作者中心取得的样本是否适用于当前主站，也以实际验证为准。

两个平台都要区分以下几种内容：

复制内容	是否是这里需要的输入
Request Headers 中的 `Cookie` 值	请求头文本导入需要的内容
Response Headers 中的 `Set-Cookie`	服务端设置指令，不是同一种格式
整段“Copy as cURL”结果	包含命令、其他头和可能的敏感信息，不能直接当 Cookie 文本
`document.cookie` 的输出	无法读取 HttpOnly Cookie，可能缺少关键字段

请求头与响应头、HttpOnly 的区别可参考 MDN Cookie 指南。真实值只在本机工具中使用，不放进博客、日志截图或公开样本。

改 Domain 或字段名，不能把凭据换成另一种

这次很容易产生一个看似省事的想法：既然要用于主站，把 Domain 改成 .kuaishou.com，或者把字段名改成成功样本里的名称，是否就能用？

这里需要分清发送范围与服务端认可。Domain、Path、Secure、SameSite 等属性影响浏览器何时携带 Cookie；目标服务是否接受它，还取决于凭据本身。

将导入 Domain 改成 .kuaishou.com，并没有执行官方登录流程，也没有签发新的主站令牌。把 kuaishou.web.cp.api_st 改名为 kuaishou.server.webday7_st，同样不会让旧值变成合法的新凭据。本次解决方式是在目标主站正常登录后，重新取得完整请求 Cookie。

另外，请求头里的 Cookie 通常只有名称和值，不包含原始 Domain、Path、过期时间、HttpOnly 等属性。两个项目对文本导入补充默认域名和路径，是代码的简化策略；需要保留原属性时，要使用工具支持的结构化格式，并检查它来自正确站点。

两个平台的差异，有一部分其实来自项目实现

核对代码后，有些看起来像“平台差异”的行为，是 dyDM 和 ksDM 当前做出的不同选择。

对比项	dyDM `c27c2d0`	ksDM `a96b329`
自动化目标	`www.douyin.com`	`www.kuaishou.com/new-reco`
Cookie 导入格式	请求头文本、Netscape 文本、JSON 数组	请求头文本、JSON 数组或含 `cookies` 数组的对象
文本导入补充属性	`.douyin.com`、`/`	`.kuaishou.com`、`/`
当前账号主页	`/user/…`	`/profile/…`
浏览器目录	已验证的抖音号及其哈希构造账号目录	独立账号 ID 下再分候选会话目录
创建上下文后的 Cookie 策略	清空后注入调用方传入的快照	新导入进入候选目录；日常使用复用当前会话
保存前的身份核对	读取完整昵称、抖音号	读取昵称、快手号及可信主页地址，已有账号还核对身份一致性

ksDM 此版本不支持导入带 origins 的完整 storage_state。支持含 cookies 数组的对象，不代表同时支持恢复其中所有本地存储。

dyDM 关注 sessionid、sessionid_ss、sid_tt 等字段来协调浏览器任务，也不意味着这些名称就是抖音登录的完整必填协议。上述格式、目录与更新策略都以列出的代码版本为准。

不能把这张表写成“抖音要求每次清 Cookie，快手禁止清 Cookie”。这是实现差异，平台认证是否成功仍由目标业务验证。

让新导入先验证，再替换原会话

Cookie 是某个时刻的快照，浏览器会话还可能包含 localStorage、IndexedDB 等状态。站点登录后也可能更新 Cookie。反复把早先保存的快照注入正在使用的目录，可能覆盖更新后的值。

ksDM 当前为新 Cookie 导入和重新登录建立候选会话。只有从候选会话读到可靠的主页资料，并成功保存账号记录，才把它切换为当前会话。失败或取消，不覆盖原来的已验证会话。

日常验证和打开主页则复用保存的目录，不再每次导航都清空本地存储。这个策略使“尝试一份新 Cookie”与“继续使用原账号”可以分开处理。

新 Cookie 在候选会话中验证，通过后才切换账号记录，失败保留原会话

使用持久目录也不能保证所有状态永远有效。尤其 sessionStorage 不能仅凭目录持久化就承诺跨重启恢复；Cookie 快照、完整认证状态导出与持久浏览器目录，是不同的保存方式。Playwright 认证状态文档说明了存储复用及 sessionStorage 的单独处理方式。

对比之下，dyDM 当前在创建上下文后执行 clear_cookies()，再 add_cookies(cookies)，其他本地状态可随持久账号目录保留。它的 Cookie 更新策略与 ksDM 不同；排查时应检查调用方传入的是哪一份快照，而不是只看到目录存在，就认为会话一定完整。

找到用户主页，还要确认是谁的主页

推荐页同时存在当前账号头像和视频作者头像。读到一个 /profile/… 链接，只能说明找到了某个人的主页。

本次快手入口适配针对带“我的”标记的当前账号控件，处理悬停、点击昵称和头像，再等待官方主页地址。示意结构如下，昵称仅为占位：

<div class="user item">
  <img class="image" alt="当前账号头像">
  <div class="text"><div class="text-name">示例昵称</div></div>
  <div class="text-fold">我的</div>
</div>

程序不依赖个人昵称、真实头像 URL 或 Vue 的 data-v-* 哈希，也排除推荐作者卡片。与抖音适配时一样，优先通过“我的”等当前账号导航进入主页，再读取身份。

Cookie 中的 userId、uid_tt 等内部标识也不直接充当面向用户展示的快手号或抖音号。保存账号前，需要从经过验证的当前账号主页读取昵称和平台账号。

这部分交互已有真实 Chrome 的离线页面验证，但离线验证不等于已经完成有效登录会话中的线上交互验收。选择器是否适应当前网页、最终保存的身份是否正确，仍需在实际会话中确认。

下次遇到“导入了却没登录”，按这条线检查

先核对目标页面和 Cookie 来源，再检查导入格式与实际发送的 Cookie；接着比较账号业务响应和页面状态，最后核对当前账号身份及保存后的复用。每一步都保留它自己的结果，不用前一步的成功替后一步作结论。

看到的现象	优先核对
浏览器启动失败	浏览器路径、目录占用、启动阶段错误
Cookie 导入报错	文本或 JSON 格式、属性是否被当前工具支持
导入无报错，仍显示登录按钮	来源业务是否正确、目标请求是否携带凭据、页面是否接受
HTTP 200，但页面未登录	响应体的业务结果与实际页面状态
能打开主页，却读到别人的信息	当前账号入口与推荐作者入口是否混淆
本次成功，下次失败	快照是否过旧、会话是否更新、保存和复用是否正确

这次快手问题最终通过更换主站样本确认了登录来源的重要性。它提供的是一条可复查的排查路径：复制之前确认业务，导入之后验证目标页面，保存之前核对当前身份。

案例与代码依据

dyDM 使用指南、Cookie 解析、浏览器会话管理：获取说明、导入格式和会话策略。
ksDM 账号验证实现、开发记录：此次样本来源、登录反馈、候选会话和当前账号入口适配。

上述提交固定了本文比较的版本。浏览器通用文档用于解释 Cookie 和存储机制，不提供快手、抖音的完整认证字段协议。