想把短信、公众号菜单、二维码里的长链接压短，又不想一个个手工贴进网页生成器，最直接的办法就是接一个能批量调用的接口。真去搜"百度短网址生成 api"，会撞上两种截然相反的信息：一种是满屏的免费调用示例，另一种是"这服务早就停了"。两种说法都不算错，只是说的不是同一件事。
现在想做短链 API，能走的路就三条
| 1 | 百度智能云短网址服务：正规云服务，实名开通，按创建条数与跳转次数计费 |
| 2 | 网上流传的 dwz.cn 免费接口：域名还在百度手里，但对个人的生成入口早已关闭 |
| 3 | 开源自建：买个短域名搭一套自己的短链服务，数据、规则、域名都在自己手上 |
一、dwz.cn 那套流传的接口，为什么调不通了
先把历史捋清楚，才能明白那些调用示例为什么失效。百度在短网址这件事上折腾过两轮，域名几经更替，对外的开放程度也一直在收。
百度推出短网址服务，用的是自家域名，被网友调侃过"域名最长的短网址"，上线不久即关闭。
百度低调重启短网址，启用了两个字母的域名 dwz.cn，这个域名是收购来的。之后很多年，它成了站长和运营手上最常见的短链工具。
平台曾提供带鉴权参数的接口，用来批量生成短链。那套参数格式被大量博客、教程抄走，一直流传到今天，成了"网上搜到就能抄"的代码。
dwz.cn 首页的公告写得很直白：为满足 *** 相关监管部门关于链接跳转内容的监管要求，打击利用短网址从事诈骗、涉黄涉暴等非法行为，短网址服务已不再对外开放生成。域名还在，个人拿不到新的短链。
所以那些"照着抄就能用"的调用示例，现在跑出来的结果通常是鉴权失败或者直接超时。接口是真实存在过的，只是这条通道已经关了对个人开放的门，代码本身没写错，环境变了。
别再花钱买所谓"百度短网址源码""内部接口账号"这类东西。老的开放通道已经停用，兜售这套说辞的多数是在卖一份过期的教程。更别把个人 token 写进前端代码里，泄露出去就等于把账号交出去。
二、还在运营的 *** 路径：百度智能云短网址服务
如果非要走百度的通道，现在能打的正门是百度智能云的短网址服务。它在云产品的名录里，定位是网址缩短加营销数据分析，做的事情和当年那个免费工具不太一样：面向的是有投放、有短信、有大批量分发需求的商用场景。
计费方式也和免费工具时代大不相同。按 *** 文档的口径，费用由两部分构成：创建短网址的条数，以及短网址产生的跳转次数，实行阶梯定价。用量小的时候单条成本不高，量一大就得先算一笔账。开通走云平台的标准流程，需要实名认证，之后还要在访问控制里给子用户分配权限，调用沿用百度智能云统一的鉴权机制。
// 调用结构示意，具体接口地址、字段与签名方式以百度智能云 *** 文档为准POST /<接口路径> HTTP/1.1Host: <服务域名>Authorization: bce-auth-v1/<AccessKeyId>/<时间戳>/<有效期>/<签名头>Content-Type: application/json{"url": "https://www.example.com/very/long/path?id=123","shortDomain": "<已开通的短域名>","expireDays": 365}它的优势在于不用自己运维，跳转稳定性和数据统计都是现成的，跳转数据还能当营销分析的原料。代价是成本随用量走，并且短链挂的是平台域名而不是你的品牌域名。做投放的人对口子里的域名往往有要求，这一条要提前想清楚。
适合走云服务
短信群发、信息流投放、需要正规发票与合规链路、内部没有开发资源的团队。用量有波动也没关系，跳转次数计费天然按量走。
适合自己搭
量稳定且大、要求短链带自己品牌域名、需要自定义跳转规则（按地区、按时段、按设备分流）、数据必须留在自己数据库里的场景。
三、自己搭一套：从域名到接口跑通，一个下午够了
自建短链是这几年最稳的选择，理由不复杂：域名在自己手里，规则自己定，第三方停服也影响不到你的存量链接。门槛也没想象中高，三样东西凑齐就能开工：一个尽量短的域名、一台能跑脚本的服务器加数据库、一段生成与跳转的逻辑。
# 最小可用的短链生成 + 跳转示例（Flask + SQLite，可直接跑）from flask import Flask, request, redirect, jsonifyimport sqlite3, string, randomapp = Flask(__name__)BASE = "https://s.example.com/" # 换成你自己的短域名def db():conn = sqlite3.connect("short.db")conn.execute("CREATE TABLE IF NOT EXISTS links (code TEXT PRIMARY KEY, url TEXT)")return conn@app.route("/api/create", methods=["POST"])def create():url = request.json.get("url", "")if not url.startswith(("http://", "https://")):return jsonify({"ok": False, "msg": "url 必须以 http(s) 开头"}), 400code = "".join(random.choice(string.ascii_letters + string.digits) for _ in range(6))conn = db()conn.execute("INSERT INTO links (code, url) VALUES (?, ?)", (code, url))conn.commit(); conn.close()return jsonify({"ok": True, "short": BASE + code})@app.route("/<code>")def jump(code):row = db().execute("SELECT url FROM links WHERE code = ?", (code,)).fetchone()return redirect(row[0], code=302) if row else ("not found", 404)if __name__ == "__main__":app.run(host="0.0.0.0", port=8000)这段代码跑起来就是一个能用的接口：POST 一个长链接进去，返回六位的短码。实际投产还要补几件事，代码升级成六个字符以上的随机码防止被猜，加上生成频率限制防止被刷，跳转记录写进单独的点击表方便统计。开源社区里现成的程序也不少，PHP 加 MySQL 的轻量程序支持接口生成与伪静态跳转，功能更全的平台型程序还带后台、分组和访问报表，选一个拿来改比从零写快。
域名这一环容易踩空：短链用的域名最好和主站分开，收到短信链接被平台拦截时不至于连累主域名；域名按要求完成实名与备案，跳转目标不要涉及违规内容，短链一旦被用于导流到不合规页面，最先被处理的是这个域名。自建省的是服务费，不是合规成本。
两种方式的数据能力也有区别。云服务自带跳转分析报表，适合只看结果的人；自建的话点击明细都在自己库里，能按渠道、时段、设备随便拆，缺点是这套报表要自己写。做站群或投放矩阵的人通常更看重后一种，因为数据留在自己手上，随时能换统计口径。
四、短链拿去用的时候，几个平台各有脾气
接口跑通只是第一步，短链发到不同渠道里能不能点开，是另一回事。同一批短链，投短信没问题，发进某些应用的内置浏览器可能就被拦。
| 使用场景 | 常见用法 | 要注意的点 |
|---|---|---|
| 短信 | 长链压短降低计费条数，批量生成后按批次发 | 运营商对含链接的营销短信审核严格，短域名要提前报备 |
| 公众号与社群 | 菜单、自动回复、社群公告里替换长链接 | 外部链接在内置浏览器里打开，跳转目标别设置成自动下载 |
| 二维码 | 印制物料上放短链二维码，图案密度更低更好扫 | 印刷品无法事后改链接，短链的跳转规则要留好修改余地 |
| 站内跳转 | 外链统一走自己的短链域名，跳转数据集中统计 | 用于跳转的域名不要和内容站混用，免得被垃圾外链牵连 |
还有一个反过来的问题：短链把目标网址藏起来，点击的人看不到去向，平台方也因此加强了对短链的审核。自建短链时保留一层"跳转前提示"的能力会更有余地，遇到平台或客户要求可追溯时能直接给出目标地址。
做 SEO 的人还会问能不能把短链当外链用。答案是不建议：短链收到的是跳转信号，权重传递和直接给目标地址不是一回事，短时间内大量发同域短链，更像在做痕迹明显的批量操作。
五、跳转方式、还原办法，还有那条被误认的百度链接
短链的技术内核其实只有一行跳转指令，但这一行选 301 还是 302，会实打实影响后面的效果和数据。
- 302 临时跳转：绝大多数短链服务的默认选择。计数准确，地址可以随时改，链接被浏览器记住的概率低，适合投放、活动这类需要随时调整目标的场景。
- 301 永久跳转：会被浏览器和搜索引擎长期记住，跳转次数统计会失真，因为第二次点击可能都不经过你的服务器。目标地址一旦定死基本不能改。
- 跳转中间页：先落在一个提示页再跳走，多一次点击，换来的是可追溯和可拦截，金融、医疗这类敏感行业有时宁可牺牲一点转化率换合规。
- 短链还原：把短链的跳转过程跟一遍就能拿到目标地址，手动点开看地址栏，或者用抓包工具看响应头里的 Location 字段，都比重装一个插件省事。
顺带澄清一个常被混淆的东西：百度搜索结果里那些一长串带参数的地址，是搜索引擎自己的跳转统计链接，用来记录点击、做反作弊判断，它不是短链服务，也没有对外开放的生成接口。想还原真实目标地址，跟一次跳转就能看到，但这属于使用搜索引擎的正常现象，拿去批量采集就变味了。
自建短链一定要做跳转目标校验。短链被滥用最多的场景就是拿别人的域名去跳诈骗、涉赌、涉黄页面，域名一旦被标记，短信通道和搜索收录都会跟着受影响。生成接口至少要做白名单或人工审核，历史链接定期巡检。
六、动手选之前，先把这几个问题问清楚
短链这种东西做好了没人夸，出事了全是麻烦，因为它挂在短信、物料、公众号里，换起来成本极高。定下来之前把下面几件事确认掉，后面能省下大量返工。
用第三方平台，域名是别人的；平台调策略或者停服，你印在包装上的二维码就成了死链。这类事故以前发生过不止一次。
一次要生成几百上千条的时候，接口的并发上限和失败重试机制比单价更重要。有没有批量接口，直接决定你要不要写循环脚本。
点击明细、来源渠道、时间分布，能不能一次性导出成表格。换服务商时，数据带不走的代价比费用本身大。
有没有有效期、到期后是失效还是自动续。做过活动的人都知道，物料印出去之后链接失效，补救只能靠重新投一遍广告。
免费短链平台能长期用吗？
免费的东西要么靠广告补贴、要么靠后面的增值服务，两种都可能在某一天改变规则。临时活动用一下问题不大，要把短链印进包装、写进短信模板、投进广告计划，就得按"这条链接要活好几年"的标准去挑。
自建短链要不要单独买服务器？
跳转服务很轻，一台最低配的机器就能扛住很大流量，也可以和现有站点放在同一台机器上用不同域名区分。真正影响体验的是解析速度和线路质量，短链在短信里被点了之后打不开，用户不会认为是服务器问题，只会觉得这家公司不靠谱。
七、短链管的是分发，内容能不能被搜到是另一条线
短链做的是把已有的地址变短，让它在短信里少占几行、在二维码里更密实。它解决的是分发环节的效率，不解决"这个页面有没有人搜得到"。两条线经常被混在一起谈，其实是性质不同的两件事：一条是自己主动发给用户，一条是等用户上门。
页面用 HTML 直接把内容输出，爬虫拿到的就是完整文字，不用等脚本渲染完再判断。
新内容生成后同时走百度 API 与 IndexNow，让两个抓取入口都尽早收到这条新地址。
索引量、排名、抓取异常集中在一个界面，哪个页面没进索引能直接定位。
站点环境各自独立，某一台出故障不会牵连其他站，短期波动也不会互相拖累。
用 UC 建站系统做内容站，这几件事能压成固定流程：页面 HTML 直出，抓取时拿到的就是完整正文；内容生成后自动推送两个通道，省掉逐条手工提交；多站数据汇总在一处看；各站独立部署互不影响。这么安排的意义在于，把分发（短链、短信、广告）和承接（能被搜到的内容页）两条线分开，各自用合适的工具，别指望一个短链接口把两边的事都办了。
建站系统解决的是"让页面更容易被抓到、更快被发现"，是否收录、排在第几由搜索引擎的抓取与排序机制决定，任何工具都不能替代这个判断，本文也不做收录与排名承诺。
把这件事收个尾：要短链接口，先接受一个前提，百度那套免费开放的时代已经过去，现在的正门是云服务，按用量付费；不想按量付，就把短链握在自己手里，一个短域名加一段脚本，成本固定、规则自定，代价是运维和合规都要自己兜。
无论选哪条路，落笔之前都值得想一遍：这条链接要发到哪里去、要活多久、失效了会有什么后果。想清楚这三个问题，路子基本就定了，剩下的都是执行。
（文中涉及的短网址服务现状、计费口径与接口形式，以百度智能云 *** 文档及服务页面当期说明为准；开源项目的字段与部署方式以对应项目文档为准。短链跳转内容须符合法律法规与平台规则，本文不做收录、排名或跳转可用性承诺。）
