---
title: "快手与抖音 Cookie 获取和使用差异：导入成功，为什么还没登录？"
source: https://www.iowill.com/blog/2026/10/kuaishou-douyin-cookie-login-differences/
date: 2026-10-20
updated: 2026-10-20
tags: [Cookie, Playwright, 快手, 抖音, 故障排查, 浏览器自动化]
categories: [编程开发]
---

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

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

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

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

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

## 先确认 Cookie 是从哪个页面取来的

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

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

```text
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，响应体却是：

```json
{"result": 109}
```

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

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

如果只在 `add_cookies()` 没有报错时就提示“登录成功”，这个问题就会被藏起来。注入接口负责把数据放进浏览器，不替目标服务判断凭据是否有效。参数与作用范围可查 [Playwright add\_cookies 文档](https://playwright.dev/python/docs/api/class-browsercontext#browser-context-add-cookies)。

![Cookie 导入、业务登录与当前账号身份是三个独立检查步骤](https://img.iowill.com/file/%E7%BC%96%E7%A8%8B%E5%BC%80%E5%8F%91/%E5%BF%AB%E6%89%8B%E4%B8%8E%E6%8A%96%E9%9F%B3Cookie%E8%8E%B7%E5%8F%96%E5%92%8C%E4%BD%BF%E7%94%A8%E5%B7%AE%E5%BC%82/body1.png)

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

## 从目标站点获取请求 Cookie

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

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

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

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

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

dyDM 原指南的入口是[抖音创作者中心](https://creator.douyin.com/)，这是已有项目说明。若排查的是主站自动化问题，可以先在 `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 指南](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Cookies)。真实值只在本机工具中使用，不放进博客、日志截图或公开样本。

## 改 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 在候选会话中验证，通过后才切换账号记录，失败保留原会话](https://img.iowill.com/file/%E7%BC%96%E7%A8%8B%E5%BC%80%E5%8F%91/%E5%BF%AB%E6%89%8B%E4%B8%8E%E6%8A%96%E9%9F%B3Cookie%E8%8E%B7%E5%8F%96%E5%92%8C%E4%BD%BF%E7%94%A8%E5%B7%AE%E5%BC%82/body2.png)

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

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

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

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

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

```html
<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 使用指南](https://github.com/Billy775326/dyDM/blob/c27c2d0/docs/USER_GUIDE.zh-CN.md)、[Cookie 解析](https://github.com/Billy775326/dyDM/blob/c27c2d0/src/cookies.py)、[浏览器会话管理](https://github.com/Billy775326/dyDM/blob/c27c2d0/src/browser_profiles.py)：获取说明、导入格式和会话策略。
-   [ksDM 账号验证实现](https://github.com/Billy775326/ksDM/blob/a96b329/ksdesktop/session.py)、[开发记录](https://github.com/Billy775326/ksDM/blob/a96b329/docs/DEVELOPMENT.md)：此次样本来源、登录反馈、候选会话和当前账号入口适配。

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