之前写有道词典开放接口盘点时，我注意到有道单词本也有网页接口，但它和查词接口不一样：查词可以公开访问，单词本的增删操作需要登录态。
这次我把它接进自己的生词复习工具：点击一个单词的「认识」，复习进度照常记录，有道网页版单词本里的对应词条也会删除，项目里的词库同步移除。
想解决的问题
以前，点「认识」只代表复习工具记下“我认识这个词”，有道单词本里它仍然留着。复习工具和单词本各记各的，过一阵子两边就对不上。
我希望把这个动作连起来：
- 页面点击「认识」；
- 保存本项目的复习记录；
- 从有道网页版单词本删除对应词条；
- 从项目词库中移除这个词。
公开查词接口和登录态接口是两回事
查词、音标、例句等内容可以通过公开词典接口获取；但读取和修改个人单词本属于账号数据，需要已登录的 Cookie。
这次用到的单词本接口包括列表查询和按词条 ID 删除。实现时不是直接猜一个词名就发删除请求，而是先用登录态分页读取单词本，找到大小写不敏感、词形完全匹配的条目，再按返回的 itemId 逐条删除。这样既能确认目标，也能处理单词本里意外存在的重复词条。
Cookie 是怎样“共享”的
这里的“共享”不是浏览器之间自动同步 Cookie，也不是把微信账号授权给了复习工具。实际过程是用户主动把已登录请求中的 Cookie 凭证交给自己控制的服务端，再由该服务端代为访问有道：
- 在浏览器登录有道单词本；微信扫码只是完成登录的一种方式。
- 打开浏览器开发者工具的 Network（网络），刷新单词本页面。
- 找到发往
dict.youdao.com、用于读取单词列表的请求，在 Request Headers（请求标头）里复制Cookie。 - 将 Cookie 粘贴到复习工具设置中，先验证登录态，再保存。
- 服务端使用这段登录态请求有道单词本；浏览器本身不需要直接调用有道的删除接口。
开发时我也试过直接用自动化浏览器处理登录。后来发现它和我日常使用的浏览器是不同的会话环境：自动化页面并不会自动继承个人浏览器里的微信登录状态。最直接的办法，是在已经登录的浏览器中查看对应请求，再把 Cookie 交给目标应用。
工具设置框支持粘贴 Cookie 值或整段请求头，服务端只提取 Cookie 行。读取配置时只返回“是否已设置”，不会把凭证再回传给页面。
实际结果
登录态验证通过后，我在复习页面点了一个单词的「认识」，随后去有道单词本确认，词条确实少了一条。项目这边也会从词库中移除该词；如果有道请求失败，项目仍保留本地复习进度，并把删除失败原因提示出来。
还要区分两份数据：有道网页版单词本和电脑上的有道词典数据文件不是同一个存储位置。工具不会直接改电脑上的数据库；我确认同一账号的桌面端已经同步后，后续词库同步也不会再导入这个词。
Cookie 不是普通配置，而是登录凭证
Cookie 通常可以代表一个已登录会话。拿到它的人，在有效期内可能可以执行该账号允许的操作。它不是“无害的接口参数”，也不应该公开分享。
- 不要把 Cookie 发到聊天、邮件、Issue 或公开仓库。
- 只粘贴到自己控制、明确可信且启用 HTTPS 的服务。
- 不要在 HTTP 明文页面提交 Cookie；网络链路上的其他人可能截获它。
- 不要把 Cookie 写进日志、前端代码或会被提交的配置文件。
- 如果怀疑泄露，应退出登录或撤销相关会话，并重新验证、更新凭证。
这次联调也让我意识到：密码保护不等于传输加密。即使只有自己能打开的页面，只要浏览器到服务端还是 HTTP，Cookie 仍可能以明文经过网络；公网使用前，必须先让整个访问链路启用 HTTPS。如果已经通过 HTTP 提交过有效 Cookie，应先注销或撤销旧会话，再通过 HTTPS 重新配置。
这次接入最有价值的地方，不只是多调通了一个接口，而是把“复习时的判断”真正连回了单词本。与此同时也提醒自己：能复用登录态，不代表应该随意转交登录态。
本文章永久链接： Cookie 不是自动共享：我给有道单词本接上了认识即删除