CSDN Markdown自动发布踩坑记录与解决方案

CSDN Markdown自动发布踩坑记录与解决方案最近把本地 Markdown 自动发布到 CSDN 这件事完整跑通了一遍中间遇到了不少真实问题。这篇文章主要记录整个排查过程、最终方案以及后续使用时需要注意的几个点方便后面继续维护。一、目标最开始的目标比较明确本地 Markdown 文件可以一键正式发布到 CSDN第一次登录后保存 Cookie后续直接复用自动从文章内容或文件名生成标签监控blog目录下新增的 Markdown已发布的不重复发布未发布的自动发布不需要一直开着一个 shell 窗口二、遇到的问题1. 首次登录时出现 403 Forbidden一开始直接访问https://editor.csdn.net/在未登录的新会话下会出现403 Forbidden导致误以为脚本登录逻辑有问题。后来核对 CSDN 当前发布页面后确认首次登录入口不能直接用editor.csdn.net更稳妥的入口应当是https://mp.csdn.net/edit未登录时会自动跳转到passport.csdn.net登录页这一步修正后首次登录流程才稳定下来。2. 只想第一次登录后续直接复用 Cookie实际需求并不是每次发布都打开浏览器登录而是第一次手动登录保存浏览器登录态和 Cookie 快照后续发布默认直接使用本地 Cookie最终脚本支持了这套方式python .\csdn_publish.py login登录后保存到.csdn_profile同时保存 Cookie 快照到.csdn_cookies.json后续发布默认直接读取 Cookie 快照这样平时发布不需要反复登录只有登录态失效时才需要重新执行一次login。3. 正式发布时标题长度不够排查发布接口后确认CSDN 正式发布时对标题长度有明确要求标题不能少于 5 个字标题不能超过 100 个字因此脚本里补了本地校验发布前就会先检查标题避免请求发出去后才报错。4. 正式发布时必须至少有一个标签继续核对发布页面和实际请求后发现pubStatuspublish的正式发布场景下至少要有 1 个标签否则会被 CSDN 拒绝所以脚本后来增加了自动标签生成能力在没有显式提供tags时会从下面几类信息里推断文件名文章标题所在目录名这样即使文章没有手动写标签也能尽量满足正式发布要求。5. 调试失败信息都落在.csdn_debug发布失败后脚本会把错误上下文写到.csdn_debug目录这本身是对的但如果不知道这个机制就会感觉“只看到报错在.csdn_debug却不知道问题是什么”。现在的做法是发布失败时保留请求 payload同时记录错误信息方便后续快速定位是标题、标签、Cookie 还是接口变化导致的问题三、现在的发布方案现在已经形成了一套比较稳定的流程第一步首次登录python .\csdn_publish.py login这一步只需要做一次。登录成功后后续发布默认直接复用 Cookie。第二步单篇发布python .\csdn_publish.py publish D:\XuJunWei\QT\qtTools\blog\xxx.md第三步监控 blog 目录自动发布python .\blog_watch_publish.py监控脚本会递归扫描blog目录发现新的.md文件就自动发布已成功发布的文件不会重复发布失败的文件会按设定间隔重试发布状态保存在.csdn_publish_state.json四、后台运行的优化如果直接在命令行里运行监控脚本会一直占用一个终端窗口不够方便。为了解决这个问题后来又补了后台运行方案start_blog_watch.cmdstatus_blog_watch.cmdstop_blog_watch.cmdinstall_blog_watch_task.cmduninstall_blog_watch_task.cmd现在推荐的使用方式是1. 手动后台启动start_blog_watch.cmd --interval 30启动后窗口可以直接关闭监控器仍会在后台运行。2. 开机后自动后台启动install_blog_watch_task.cmd --interval 30这样以后每次登录 Windows监控器都会自动启动不需要再手动开 shell。五、Cookie 过期怎么办这也是实际使用中非常关键的一点。目前脚本对 Cookie 的处理逻辑是默认使用第一次保存下来的 Cookie 快照如果 Cookie 已过期发布会失败但不会误判为成功失败记录会写入状态文件和调试日志重新执行一次python .\csdn_publish.py login后后续可以继续发布如果想尽量降低 Cookie 过期带来的影响可以在后台监控时加上start_blog_watch.cmd --interval 30 --refresh-cookies或者安装任务计划时这样写install_blog_watch_task.cmd --interval 30 --refresh-cookies这会让脚本在每次发布前尽量从本地浏览器配置目录刷新一次 Cookie。不过要注意这并不等于“完全自动重新登录”如果浏览器本地登录态还有效通常可以自动刷新 Cookie如果 CSDN 要求重新扫码、重新输密码或验证码仍然需要手动执行一次login六、Markdown 头部那段 front matter 每篇都要写吗很多人看到下面这种格式会担心是不是每篇文章都必须手动写--- title: CSDN Markdown自动发布工具使用教程 category: 工具 tags: [Python, 自动化, CSDN, 效率工具] description: 详细介绍如何使用Python脚本实现本地Markdown文件一键发布到CSDN ---答案是不是必须每篇都写。当前脚本已经支持下面这套优先级title先用命令行传入的标题再读 front matter 里的title再从正文第一个一级标题提取最后退回到文件名tags先用命令行--tags再读 front matter 里的tags如果都没有就自动生成标签description先用命令行--description再读 front matter如果都没有就自动截取正文生成摘要category先用命令行--category再读 front matter如果都没有当前默认就是空也就是说title可以自动推断tags可以自动生成description可以自动摘要category目前最好手动给或者统一在命令行指定七、front matter 能不能用脚本自动生成答案是可以分两种思路。方案一不真正写回文件只在发布时自动推断这是当前脚本已经在做的事情也是我更推荐的方式。优点原始 Markdown 更干净不需要每篇文章都手工补头信息发布时自动生成标题、标签、摘要缺点文章文件本身看不到最终元信息如果你以后还想把同一篇文章发到别的平台元数据不够直观方案二额外写一个预处理脚本把 front matter 自动补到文件头这也是可行的。可以做成这样的逻辑如果文件开头没有 front matter就自动生成一段title取一级标题或文件名tags从标题、目录、关键词中提取description从正文前几段自动摘要category按目录名映射生成优点每篇 Markdown 都带完整元信息更适合多平台复用后期人工检查也方便缺点会直接改动原始文件自动生成内容有时还需要人工微调八、推荐做法结合目前这套工具最实用的建议是对普通文章可以不写 front matter直接依赖脚本自动推断标题从一级标题或文件名取标签自动生成描述自动摘要对重要文章建议手动写一个最小 front matter只保留最关键的字段--- title: 你的文章标题 category: 工具 tags: [Python, CSDN] description: 一句话摘要 ---这样可控性更高也更适合正式发布。对长期批量写作最推荐的做法是平时允许脚本自动生成标签和摘要重要文章再手动补 front matter如果后续文章数量很多再单独加一个“自动补 front matter”的预处理脚本九、总结这次把本地 Markdown 自动发布到 CSDN 的流程跑通后几个关键问题基本都解决了修正了首次登录入口解决 403 问题支持首次登录保存 Cookie后续直接复用增加了标题和标签校验避免正式发布失败支持自动生成标签支持监控blog目录并自动发布新文件增加后台运行和开机自启能力明确了 Cookie 过期后的处理方式如果只是追求好用完全可以不要求每篇 Markdown 都手写 front matter。现在这套脚本已经能自动补足大部分元信息只有category这种强业务字段才更适合手动指定或做目录映射。如果后面文章数量继续增多再补一个“自动生成并写回 front matter”的辅助脚本就是下一步很自然的优化方向。