企业官网建设流程全解析

• 桌面应用
• 音视频

本文围绕 BiliTools（基于 Tauri 的哔哩哔哩桌面工具箱）的账号登录功能展开，系统性讲解三种登录方式的成功率差异与适用场景、登录过程的“模拟 Chrome”底层原理、登录后账号后台显示“Chrome 浏览器”与“未知设备”的原因，以及通过 SQLite 数据库直接导入官方 Cookie 的完整实操步骤，并补充登录后 Cookie 刷新、退出登录与风控防护的工程实现细节，帮助你在实际使用中选对登录方式、规避风控并安全地管理账号凭据。

一、登录方式总览：成功率与适用场景

在 docs/guide/login.md 中，项目官方给出的登录方式成功率排序为：

扫码登录 > 短信登录 > 密码登录

这一排序并非偶然，而是与哔哩哔哩 Web 端风控策略的强度直接相关：

• 扫码登录：由于整个过程几乎等同于“在 Chrome 中打开登录页并扫码”，与真实用户行为一致，因此成功率最高。
• 短信登录：需要先通过极验（Geetest）图形验证码，再输入短信验证码，成功后会返回refresh_token并写入本地 Cookie 库，登录后账号后台会提示 “未知设备”。
• 密码登录：当前版本 src/services/login.ts 中保留了完整实现（RSA 公钥加密密码 + 极验验证码），但官方明确说明“密码登录目前因风控问题暂不可用”，即后端风控会拒绝该方式，不建议再依赖它登录。

[!TIP] 如果你在官网已经登录过，最稳妥的途径其实是直接导入官方 Cookie（见下文第三节），完全绕开以上三种方式的风控差异。

二、底层原理：登录本质是“模拟 Chrome 浏览器”

BiliTools 的登录逻辑完全基于哔哩哔哩的Web API，因此登录过程实质上是模拟 Chrome 浏览器的登录过程。这一点在 docs/guide/login.md 中有明确说明，并且在前端与后端的实现中都有大量佐证：

2.1 固定的浏览器指纹与请求头

在 src-tauri/src/shared.rs 中，项目硬编码了与浏览器一致的User-Agent：

pub const USER_AGENT: &str = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36";

同时 Headers::new() 会为所有请求注入默认的Referer: https://www.bilibili.com/与Origin: https://www.bilibili.com，并且在每次登录/刷新 Cookie 成功后调用HEADERS.refresh()，将数据库中所有 Cookie 重新拼接为Cookie头（见 shared.rs）。

正因为请求指纹被伪装成了 Chrome 浏览器，登录后你在哔哩哔哩账号后台看到的登录设备提示，很大概率是 “Chrome 浏览器”。

2.2 登录前的环境准备：buvid / b_3、b_4、_uuid 与风控票据

在真正发起登录请求前，后端会先完成一组“模拟浏览器”的前置步骤（见 src-tauri/src/services/login.rs）：

1. get_buvid()：先请求https://www.bilibili.com首页，从响应Set-Cookie头中收集buvid3等初始 Cookie；再请求https://api.bilibili.com/x/frontend/finger/spi获取b_3、b_4并写入 Cookie 库（login.rs）。buvid3/buvid4是哔哩哔哩的匿名设备指纹，模拟“第一次访问网站”的行为。
2. get_uuid()：按哔哩哔哩要求的格式生成_uuid（随机段 + 时间戳 +infoc后缀）并写入 Cookie（login.rs）。
3. get_bili_ticket()：用固定密钥XgwSnGZ1p对时间戳做 HMAC-SHA256 签名，调用GenWebTicket接口获取bili_ticket风控票据（login.rs）。
4. activateCookies()：前端拿到_uuid后，还会组装一份完整的浏览器指纹 payload（屏幕分辨率、WebGL 显卡信息、字体列表、语言时区等，见 auth.ts），请求ExClimbWuzhi接口完成“指纹激活”（login.ts）。

从源码结构可以看出，登录并非“发一个请求”那么简单，而是一整套浏览器环境模拟 + 指纹激活 + 风控票据的流程，这也是项目把成功率优化到较高水平的工程基础。

三、导入官方 Cookie（数据库直写方式）

如果你在哔哩哔哩官方网站已经获取了 Cookie 序列，可以通过编辑应用数据库的方式直接使用这些 Cookie，完全跳过应用内登录。

[!CAUTION]编辑数据库有一定风险，请确保你知道自己正在做什么。建议先备份Storage文件再操作。

3.1 定位应用数据库

应用数据（包括 SQLite 数据库Storage）按平台存放于以下目录：

该路径由 src-tauri/src/shared.rs 中的STORAGE_PATH定义，数据库以WAL 模式打开并存储为Storage文件（见 src-tauri/src/storage/db.rs）。

3.2 操作步骤

1. 使用支持 SQLite 的数据库编辑器（如 DB Browser for SQLite、SQLiteStudio 等）打开上述Storage文件；
2. 切换至cookies表；
3. 将你在官网获得的 Cookie 序列（形如SESSDATA=xxx; bili_jct=xxx; DedeUserID=xxx; ...）拆分成键值对，逐条插入数据库；
4. 其余字段（如path、domain等）可以留空；如果你知道如何获取这些字段，也可以一并填入，以获得更精确的匹配。

3.3 数据库表结构与写入规则（源码依据）

cookies表的结构定义在 src-tauri/src/storage/cookies.rs：

其中name是主键，因此同名的 Cookie 只保留一行。应用内部写入时使用的是“先解析Set-Cookie字符串、再按name冲突更新（ON CONFLICT ... UPDATE）”的语义（见 cookies.rs），你手动插入时同样按name去重即可。

3.4 导入后如何生效

Cookie 写入数据库后，应用会通过HEADERS.refresh()把库中所有 Cookie 拼成Cookie头注入后续请求（见 shared.rs）。也就是说，只要 Cookie 有效，应用即可直接解析对应账号可访问的资源。参考讨论见仓库官方 Discussion #152（文档中提及的外部链接此处不展开）。

[!NOTE] 哔哩哔哩的SESSDATA等关键 Cookie 通常设置了HttpOnly与过期时间。手动插入时建议一并填入expires（Unix 秒级时间戳）与httponly = 1，避免浏览器语义不一致导致部分接口校验失败。

四、登录后的凭据维护：自动刷新与退出登录

登录不只是“拿到 Cookie”这么简单。BiliTools 在前后端都实现了完整的凭据维护链路：

4.1 Cookie 自动刷新（refresh_cookie）

哔哩哔哩 Web 登录会下发refresh_token。当接口提示需要刷新时（/x/passport-login/web/cookie/info返回data.refresh为真），前端会：

1. 用内置 RSA 公钥对refresh_<timestamp>做 OAEP 加密，得到correspondPath（见 auth.ts）；
2. 请求https://www.bilibili.com/correspond/1/<path>并解析出refresh_csrf；
3. 调用后端refresh_cookie依次完成/web/cookie/refresh与/web/confirm/refresh两个接口（见 login.rs）。

这一流程由 fetchUser() 在每次拉取用户信息时自动触发（checkRefresh()），保证长期使用的账号凭据不会因过期而失效。

4.2 退出登录（exit）

后端exit()命令会携带bili_jct作为biliCSRF请求/login/exit/v2，随后解析响应中的Set-Cookie头，逐个删除本地 Cookie 库中的对应条目（见 login.rs），并刷新全局请求头。前端用户页的退出按钮调用exitLogin()后跳转回首页（见 UserPage.vue）。

五、常见问题与风控避坑

5.1 为什么账号后台提示 “未知设备”？

• 密码/短信登录目前已知会提示 “未知设备”；
• 这是因为这两种方式没有经过完整的设备指纹“养成”流程，哔哩哔哩侧无法将登录行为与既有的浏览器设备指纹关联起来；
• 扫码登录由于手机端确认 + 完整浏览器指纹激活，通常不会出现该提示。

5.2 密码登录为什么不可用？

官方文档明确指出：密码登录目前因风控问题暂不可用。虽然前端 login.ts 仍保留“RSA 加密 + 极验验证码”的完整调用链，但哔哩哔哩侧的风控策略会拒绝这类纯 Web 模拟的密码提交。因此实际使用中请以扫码或短信为主，或直接导入官方 Cookie。

5.3 登录/使用中被风控怎么办？

登录只是起点，日常解析下载同样面临风控。结合 docs/guide/risk.md 的官方建议：

• 项目本质是模拟 Chrome 向哔哩哔哩 API 请求，参数大多来自抓包与社区讨论，无法保证每个参数都符合接口预期，因此存在被判定为爬虫的概率；
• 勾选大量任务时（应用内会有提示，不要一次性选择超过 30 个任务），依然可能触发412 Precondition Failed及其他风控；
• 官方倡导少量多次：大量内容需要下载时，建议每次勾选不超过 15 个任务，以最大程度保障账号安全。

遇到风控的处理方式：

• 若在官网发现 “大会员权限已被限制”，前往大会员页面按指引解除风控，之后使用时放慢节奏；
• 若应用内报412 Precondition Failed，要么等半个小时，要么换 IP（官方更推荐前者）；
• 非 412 的其他报错虽不排除是应用自身代码问题，也可按风控流程处理；
• 遇到任何风控都可向仓库提交 Issue 反馈。

六、总结

• 选登录方式：扫码登录 > 短信登录 > 密码登录；密码登录当前不可用，短信登录可能提示“未知设备”，但均不影响正常使用；
• 理解原理：所有登录都基于哔哩哔哩 Web API，通过固定 UA、Referer/Origin、buvid 指纹、_uuid、bili_ticket与前端指纹激活来模拟 Chrome 浏览器，因此后台常显示 “Chrome 浏览器”；
• 想直接复用官网会话：备份后使用 SQLite 编辑器在cookies表按name/value键值对插入 Cookie 即可，其余字段可留空；
• 保持账号健康：控制单次任务数量（≤15 个更安全），遇到 412 时等待或换 IP，避免触发风控。

相关文档与源码索引

• 登录官方文档：docs/guide/login.md
• 风控说明：docs/guide/risk.md
• 安装与下载：docs/guide/install.md
• 后端登录实现：src-tauri/src/services/login.rs
• Cookie 存储实现：src-tauri/src/storage/cookies.rs
• 数据库初始化：src-tauri/src/storage/db.rs
• 请求头与 UA 构造：src-tauri/src/shared.rs
• 前端登录服务：src/services/login.ts
• 前端指纹/加密工具：src/services/auth.ts
• 用户页 UI 与登录入口：src/views/UserPage.vue

• 桌面应用
• 音视频