百度网盘那个分享链接，百度点开一看，秒传八位数的短链提取码，还得复制粘贴，脚本烦。百度秒传链接倒是秒传省事，一串代码甩过去，短链对方转存就行。脚本可这串代码也忒长了，百度BDLINK开头，秒传后面跟一长串Base64编码，短链微信里发出去直接折叠成两行，脚本看着就头疼。百度
秒传短链脚本干的秒传就是这个事——把长链接压短。原理不复杂，短链找个短链服务，把秒传链接作为参数传进去，生成一个短网址。用户点开短网址，脚本自动解析出原始秒传链接，再跳转到百度网盘的转存页面。整个过程用户只看到一条七八个字符的短链，干净。
我最早用的是xtaodada那个版本，Python写的，依赖Flask和SQLite。部署在VPS上，跑起来占内存不到50M。后来自己改了几处，把短链生成算法从自增ID换成了随机字符串，省得被人遍历。数据库也从SQLite换成了Redis，响应快了不少，毕竟秒传短链这东西访问频率不高，但延迟敏感。
脚本的核心逻辑就三段：接收长链接、生成短码、存储映射关系。短码生成我试过几种方案，Base62随机六位够用，碰撞概率极低。存储这块，Redis的SET命令加个过期时间，比如七天，过期自动清理。有人问为什么不用MySQL，我说你一个个人用的短链服务，上MySQL纯属给自己找事。Redis一条命令搞定，重启还能持久化，够了。
部署完有个坑得注意。百度网盘的秒传链接格式这两年变过，早期是bdlink=xxx，后来改成bdpan://xxx，脚本得跟着更新解析规则。我那个版本里写了个正则匹配，两种格式都兼容。另外短链跳转的时候，百度那边偶尔会弹验证码，这个没法绕过，只能让用户手动点一下。脚本里加了个提示页，告诉用户“即将跳转，如遇验证请手动通过”，体验上算是找补回来一点。
实际用下来，最舒服的场景是论坛发资源。以前贴一长串秒传代码，排版乱，还容易被系统截断。现在贴个短链，干净利落。有人担心短链服务挂了链接就废了，这确实是个问题。我的做法是短链和原始链接同时保留，短链失效了还能手动恢复。另外脚本里加了个统计功能，记录每个短链的访问次数，方便判断哪些资源热门。
代码我放在GitHub上了，MIT协议，随便改。有人拿去加了前端页面，有人接了Telegram Bot，都行。这东西本身没多复杂，胜在实用。你要是也烦透了复制粘贴长链接，花半小时部署一个，一劳永逸。