简介：简洁的PHP短网址短链接生成源码，采用黑色极简视觉风格，面向需要部署私有短链服务的站长与PHP开发者。前端支持创建普通/自定义短链接、密码保护、链接统计、暗色主题、小书签及一键复制分享；后台可删除网址、编辑站点设置、添加/编辑广告、查看分析数据并自定义CSS，能独立搭建具备基础运营能力的短链系统。资源包共103个文件，约681KB，以PHP核心逻辑为主，辅以CSS/SCSS/LESS样式表、JavaScript交互脚本、字体图标及SQL数据库结构，另含少量HTML、TXT等说明文件，目录结构清晰，便于二次开发与部署。已有212人学习/下载，适合熟悉PHP、希望快速获得一套完整短网址方案或在此基础上做功能扩展的开发者。内容预览中可见其使用了常用的主流前端框架，降低了前端适配成本，整体代码量精简，部署门槛不高。
1. 黑色简洁的 PHP 短网址系统：为什么我推荐用「短码 + 302」而不是长链接直发
你身边做运营的同事是不是也常来敲你：链接太长，聊天软件里一贴占三行，外链还老被标成「不安全」。这套黑色简洁的 PHP 短网址源码就是为这种场景准备的——前台一个大输入框，长链接粘进去回车，拿到一个 6 位短码；后台能看到点击量、来源和最近记录。部署在自己服务器上，数据不出门，也不用担心第三方短链服务哪天突然停止解析。
它适合谁？PHP 新手想拆一个完整的「生成-跳转-统计」闭环；小团队需要一个能快速上线的短链工具；或者你想给现有的 PHP 软件/插件体系里加一个自托管的链接处理模块。接下来我把功能、目录、核心代码和部署步骤都过一遍，你照着就能跑起来，改也有地方下手。
2. 功能盘点与运行效果：一次点击在系统里留下的 4 条记录
2.1 核心功能清单
这类短链源码的功能通常围绕「一条链接的一生」展开：从原始长链接录入，生成短码，再到用户访问短码时触发统计和跳转。整理下来是 5 个模块加 1 个安全配置项。
| 功能模块 | 做的事 | 关键点 |
|---|---|---|
| 前台生成表单 | 粘贴长链接、输入自定义后缀（选填）、点生成 | 无刷新返回短码 |
| 短码跳转 | 访问s.example.com/{code}时读库并 302 到原地址 | 支持禁用状态 |
| 点击统计 | 记录每次访问的 IP、User-Agent、来源页、时间 | PV/UV 分开统计 |
| 管理后台 | 短链列表、删除、启停、复制、重置统计 | 独立登录 |
| 管理员登录 | Session 校验 + 密码 hash 校验 | 密码不落明文 |
除了这些，config 里还有防滥用开关：同一 IP 每分钟最多生成多少条、统计采样率等。我第一次跑起来的时候最意外的反而不是功能，而是它的统计口径分得很清楚——PV 是「每次请求 go.php 成功跳转都 +1」；UV 用 IP + User-Agent 组合取 md5 当指纹，同一天同一个指纹只算一次。这样后台的「今日点击」和「独立访客」才不会出现 300 次点击只有 5 人访问还解释不清的情况。
如果你在找 PHP 软件/插件类的自部署工具，这套源码比较难得的是它不依赖 Composer，没有 vendor 目录，解压就能用，二次开发时改单个文件也容易定位。
2.2 前台与后台的交互方式
前台是一张深色卡片，标题下是一个大输入框，右侧黑底白字的「生成」按钮，再往下是最近生成的短链列表，每条短链带一个复制按钮。整体风格和标题说的「黑色简洁」一致——没有花哨的前端框架，但该有的操作都集中在一屏内。
后台入口在/admin/，登录后看几个区块：短链列表、数据概览、设置。列表每一行显示短码、原始链接的前 40 个字符、生成时间、点击量和状态开关。数据概览用简单的柱状展示近 7 天点击趋势、来源 Top5、浏览器 Top5——都是原生 SQL 聚合查出来的，没接图表库，反而让代码更好懂。
把一次使用流程拉直看，是这样的：
| 步骤 | 操作 | 系统返回 |
|---|---|---|
| 1 | 打开首页，粘贴长链接，点生成 | 返回短码和完整短链预览 |
| 2 | 复制短链发给用户 | 用户点击，浏览器请求go.php?code=xxx |
| 3 | 系统读库校验短码 | 短码存在且状态为启用，记录统计后 302 跳转 |
| 4 | 用户落地原始页面 | 后台「最近点击」新增一条记录 |
2.3 一次点击的完整时间线
把一次点击串起来看，实际顺序是这样的：用户点短链 → 服务器收到/go/{code}或go.php?code={code}→ 查 links 表 → 写统计 → 返回 302 Location → 浏览器到目标站。关键点在于：统计必须在跳转之前完成，或者说必须和跳转在同一个请求里完成。否则一旦先跳走，后面的代码根本没机会执行。
有人会问：统计放在跳转之后用异步 JS 上报不行吗？也可以，但会漏掉「禁用 JavaScript 的访客」和「爬虫直接请求短链」这两类。所以这套源码的做法是 go.php 里同步落库再跳转，hit.php 为前台生成页面的曝光/复制事件预留了异步上报接口，两条链路互不干扰。
一次点击会在数据里留下 4 类痕迹：clicks 表新增一行明细，包含 IP、UA、指纹、事件类型；daily_visit 表当日的 PV 加 1；links 表的 click_count 冗余计数加 1；如果指纹当天第一次出现，后台的 UV 聚合结果也会跟着变化。至于 302 而不是 301，原因很直接：301 会被浏览器和搜索引擎长期缓存，改目标地址后老用户可能还停留在旧页面；开发期频繁改目标地址，用 302 能少很多「我明明改了配置为什么用户还说跳错」的翻车现场。
3. 核心模块拆解：从 index.php 入口到短码生成器的完整链路
3.1 目录结构：单入口 + 工具层 + 独立后台
我拆这类 PHP 项目，第一步永远是看目录。这套源码的目录结构非常直白：
/ ├─ index.php # 前台首页：生成表单入口 ├─ go.php # 短链跳转：读短码 → 统计 → 302 ├─ hit.php # 异步事件上报：复制、曝光等 ├─ config.php # 全局配置：数据库、域名、参数 ├─ install.sql # 初始化建表脚本 ├─ include/ │ ├─ db.php # PDO 单例连接 │ └─ function.php # 公共函数：短码生成、参数过滤 ├─ admin/ │ ├─ index.php # 后台首页：数据概览 + 短链列表 │ ├─ action.php # 后台动作：删除、启停、重置统计 │ └─ login.php # 管理员登录 └─ static/ ├─ css/style.css # 黑色简洁主题样式 └─ js/app.js # 生成请求、复制、异步上报这里值得注意的设计是：前台页面、跳转处理、后台管理三个入口互不干扰，但都复用 include 里的 db.php 和 function.php。这样你改数据库连接只需要动一个文件，新增页面时引用同一套公共函数就行。db.php 里是标准的 PDO 单例，配置来自 config.php，没有把连接信息散落在各个文件里，对新手来说这是很友好的写法。
3.2 短码生成算法：随机字符 + 冲突重试
短码生成是整个系统的门面，如果生成逻辑写得稀烂，后面所有功能都跟着别扭。常见做法是随机取字符，每次插入前查重，撞了就换一个。这套源码里对应的核心函数长这样：
// include/function.php function create_code(PDO $db, int $length = 6): string { // 去掉容易混淆的 0O1lI，避免用户看错复制错 $charset = 'abcdefghijkmnpqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ23456789'; $max = strlen($charset) - 1; for ($attempt = 0; $attempt < 5; $attempt++) { $code = ''; for ($i = 0; $i < $length; $i++) { $code .= $charset[random_int(0, $max)]; } $stmt = $db->prepare('SELECT id FROM links WHERE code = ?'); $stmt->execute([$code]); if (!$stmt->fetchColumn()) { return $code; } } // 连续冲突 5 次说明短码空间紧张，加长一位再试 if ($length >= 8) { throw new RuntimeException('short code space exhausted'); } return create_code($db, $length + 1); }几个参数我得单独说一下。$length默认 6 位，字符集 56 个字符，理论上有 560 亿种组合，日常用完全够；如果你只需要内部系统用，想短一点可以调成 4，但要接受更高的冲突概率。字符集里去掉0、O、1、l、I这五个易混淆字符，是我非常推荐的做法——用户复制短链后手工输入时，最怕的就是分不清 0 和 O。
这里用random_int而不是老项目里常见的rand()或mt_rand()，原因是前者是密码学安全随机源，生成结果不可预测，别人很难通过已生成的短码反推规律去批量扫库。冲突处理也分为两层：代码里的查重只是第一道，数据库里code字段的唯一索引才是真正的兜底，两层的成本都很低。
3.3 跳转拦截模块：从请求到 Location 的五步
go.php 是整个系统里最重要的文件，它完成了「接收短码 → 校验 → 统计 → 跳转」的全部工作。核心逻辑是这一段：
<?php // go.php require __DIR__ . '/include/db.php'; $code = $_GET['code'] ?? ''; $code = preg_replace('/[^a-zA-Z0-9]/', '', $code); if ($code === '' || strlen($code) > 16) { http_response_code(404); exit('bad link'); } $stmt = $db->prepare('SELECT id, url, status FROM links WHERE code = ? LIMIT 1'); $stmt->execute([$code]); $link = $stmt->fetch(PDO::FETCH_ASSOC); if (!$link) { http_response_code(404); exit('link not found'); } if ((int)$link['status'] !== 1) { http_response_code(410); exit('link disabled'); } // 统计：先写库，再跳转 $ip = $_SERVER['REMOTE_ADDR'] ?? '0.0.0.0'; $ua = mb_substr($_SERVER['HTTP_USER_AGENT'] ?? '', 0, 255); $fp = md5($ip . '|' . $ua); $db->beginTransaction(); try { $db->prepare('INSERT INTO clicks (link_id, ip, ua, fingerprint, event, created_at) VALUES (?,?,?,?,?,NOW())') ->execute([$link['id'], $ip, $ua, $fp, 'visit']); $db->prepare('INSERT INTO daily_visit (link_id, visit_date, pv) VALUES (?, CURDATE(), 1) ON DUPLICATE KEY UPDATE pv = pv + 1') ->execute([$link['id']]); $db->prepare('UPDATE links SET click_count = click_count + 1 WHERE id = ?') ->execute([$link['id']]); $db->commit(); } catch (Throwable $e) { $db->rollBack(); // 统计失败不阻断跳转 } header('Location: ' . $link['url'], true, 302); exit;执行顺序是：过滤参数 → 查库 → 判断状态 → 写统计数据 → 302 跳转。前两步没什么好说的，重点是第 4 步。统计放在事务里，clicks明细、daily_visit汇总、click_count冗余字段三处数据要么都成功要么都回滚，避免后台看到 PV 和明细对不上的情况。事务外面套了 try-catch，即使数据库压力大导致统计失败，用户依然能正常跳转，不会因为统计挂了而打不开链接。
关于 UV 的统计口径，daily_visit.uv字段没有在这一步更新，而是后台查询时用SELECT COUNT(DISTINCT fingerprint) FROM clicks WHERE link_id=? AND created_at>=CURDATE()实时聚合。这样少做一次「当日首次判断」，换来的是一致性——UV 永远是 cliks 明细的精确去重结果。
3.4 异步上报与防滥用：统计不拖慢跳转的小技巧
go.php 里的同步统计在低流量下没问题，但如果你把短链贴在某个大流量页面，同一秒几十个请求进来，每次都要写三张表，MySQL 压力会很明显。常见做法是加一个采样开关，config 里配stats_sample_rate，go.php 里这样用：
// go.php 统计前 if (mt_rand(1, 100) <= (int)$config['stats_sample_rate']) { // 执行上面的事务统计代码 }采样率设 100 就是全量统计，设 10 就是只统计十分之一的请求。损失是统计数字会有偏差，换来的是高并发下跳转响应更快。对内部工具来说，100 全量通常就够；对面向公网的大流量场景，我一般会调成 50 再配合后台看趋势，偏差不大但数据库压力减半。
另一个容易被忽略的是前台页面的异步上报。用户在首页生成了短链，但不一定会复制、不一定真的发出去，运营想知道「复制了多少次」，这就用到了 hit.php：
// static/js/app.js 复制按钮上报 function trackCopy(code) { fetch('hit.php?action=copy&code=' + encodeURIComponent(code), { method: 'GET', credentials: 'same-origin' }).catch(function () { // 统计失败不影响复制交互 }); }这里的action参数就是事件类型，与 clicks 表里的event字段对应，取值有 visit 和 copy 两种。credentials: 'same-origin'表示同源请求时带上 Cookie，方便后端识别同一会话。复制事件不走 302、不写 daily_visit 汇总，只在 clicks 里落一条 event=copy 的记录，后台通过event='copy'单独统计复制转化率。这个设计把「点击」和「复制」作为两道漏斗，比只堆一个总数有用得多。
4. 部署与配置手册：从压缩包解压到 Nginx 伪静态生效
4.1 运行环境准备
先确认服务器环境，这套源码要求很低，但也别在 PHP 5.6 上硬跑——旧版本的random_int不可用，短码生成会直接报错。推荐环境是这样：
- PHP 7.2 及以上，建议 7.4 或 8.0
- 必须启用扩展：pdo_mysql、mbstring、json
- MySQL 5.7 及以上，或 MariaDB 10.3 及以上
- Nginx 或 Apache 任意，不需要 Composer，没有 vendor 目录
部署第一步就是解压。把压缩包内容放到站点根目录，比如/var/www/short，然后处理权限：
# 将站点目录归属给 Web 运行用户 sudo chown -R www-data:www-data /var/www/short sudo chmod -R 755 /var/www/short # 如果源码里有 logs 目录，需要允许写入 sudo chmod -R 775 /var/www/short/logs目录权限是新手最容易忽略的一步。PHP-FPM 默认以 www-data 用户运行，如果源码目录是 root 所有，session写不进去、日志写不进去，表现就是「后台登录永远失败」或者「页面白屏但不报错」。先确认权限再做下一步，能省很多排查时间。
4.2 config.php 配置项详解
配置文件是这套源码的枢纽，所有环境相关的参数都集中在这里：
<?php // config.php return [ 'db_host' => '127.0.0.1', 'db_port' => 3306, 'db_name' => 'short_link', 'db_user' => 'short_user', 'db_pass' => '你的数据库密码', 'db_prefix' => 'sl_', 'base_url' => 'https://s.example.com', 'short_len' => 6, 'stats_sample_rate' => 100, 'admin_user' => 'admin', 'admin_pass_hash' => '', // 用 password_hash() 生成的哈希 'api_key' => '', // 如果要做对外 API，填一个随机串 'debug' => false, ];参数表如下，方便你改的时候对照：
| 参数 | 作用 | 注意事项 |
|---|---|---|
| db_host | 数据库地址 | 本机用 127.0.0.1，远程用内网 IP |
| db_name / db_user / db_pass | 库名、账号、密码 | 用最小权限账号，别用 root |
| db_prefix | 表前缀 | 建表脚本里是 sl_，改了要同步 |
| base_url | 站点完整域名 | 必须以 http(s):// 开头，结尾不要带斜杠 |
| short_len | 短码长度 | 默认 6，范围建议 4~8 |
| stats_sample_rate | 统计采样率 | 100 为全量，高并发可调低 |
| admin_user / admin_pass_hash | 后台登录凭证 | 密码永远是哈希，不存明文 |
| api_key | 对外 API 密钥 | 随机生成一串，第 6 章会用到 |
| debug | 调试开关 | 生产环境必须 false，否则会暴露 SQL 错误 |
这里最坑的是base_url。生成短链时拼接逻辑是$base_url . '/' . $code，如果你填成https://s.example.com/，生成出来的短链会变成https://s.example.com//ab12Cd，多一个斜杠，浏览器可能不认。另外admin_pass_hash留空时后台会拒绝登录，必须先跑一遍下面 4.4 里的命令生成哈希再填进去。
4.3 Nginx 与 Apache 两种伪静态写法
短链系统绕不开伪静态，你要让用户访问的是s.example.com/go/ab12Cd，而不是s.example.com/go.php?code=ab12Cd。Nginx 的配置参考这样写：
server { listen 80; server_name s.example.com; root /var/www/short; index index.php; location / { try_files $uri $uri/ /index.php?$query_string; } # 短链伪静态：/go/xxxxxx 交给 go.php location ~ ^/go/([a-zA-Z0-9]+)$ { rewrite ^/go/([a-zA-Z0-9]+)$ /go.php?code=$1 last; } location ~ \.php$ { include fastcgi_params; fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } }Apache 环境则是在站点根目录放 .htaccess：
RewriteEngine On # 短链伪静态 RewriteRule ^go/([a-zA-Z0-9]+)$ go.php?code=$1 [L,QSA] # 其余请求交给 index.php 路由 RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ index.php [L,QSA]需要注意，短码是小写字母、大写字母、数字的混合，所以正则里写[a-zA-Z0-9]，不要加i修饰符把路径改成大小写不敏感，否则ab12Cd和ab12cd会被当成同一个短码，数据就对不上了。QSA 标志是保留原有 query 参数，比如用户访问s.example.com/go/ab12Cd?utm_source=xxx，这个 utm 参数会原样透传给 go.php，方便做渠道追踪。
如果你暂时不想配伪静态，直接访问go.php?code=xxx功能完全一样，只是短链看起来没那么简洁。我建议第一次跑通时先用这个原始入口排除路由干扰，确认核心功能正常再上伪静态。
4.4 初始化数据库与验证
数据库有三张核心表加一张后台用户表？实际这套源码把管理员账号直接放 config，不建独立表，所以初始化只需要三张业务表。建表脚本 install.sql 里的核心内容：
-- 短链表 CREATE TABLE IF NOT EXISTS `sl_links` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `code` VARCHAR(16) NOT NULL, `url` VARCHAR(2048) NOT NULL, `status` TINYINT NOT NULL DEFAULT 1, `click_count` INT UNSIGNED NOT NULL DEFAULT 0, `created_at` DATETIME NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_code` (`code`), KEY `idx_created` (`created_at`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 点击明细表 CREATE TABLE IF NOT EXISTS `sl_clicks` ( `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, `link_id` INT UNSIGNED NOT NULL, `event` VARCHAR(16) NOT NULL DEFAULT 'visit', `ip` VARCHAR(45) NOT NULL DEFAULT '', `ua` VARCHAR(255) NOT NULL DEFAULT '', `fingerprint` CHAR(32) NOT NULL DEFAULT '', `created_at` DATETIME NOT NULL, PRIMARY KEY (`id`), KEY `idx_link_date` (`link_id`, `created_at`), KEY `idx_fingerprint` (`fingerprint`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 日汇总表 CREATE TABLE IF NOT EXISTS `sl_daily_visit` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `link_id` INT UNSIGNED NOT NULL, `visit_date` DATE NOT NULL, `pv` INT UNSIGNED NOT NULL DEFAULT 0, `uv` INT UNSIGNED NOT NULL DEFAULT 0, PRIMARY KEY (`id`), UNIQUE KEY `uk_link_date` (`link_id`, `visit_date`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;导入前先建库和账号：
mysql -u root -pCREATE DATABASE short_link DEFAULT CHARACTER SET utf8mb4; CREATE USER 'short_user'@'localhost' IDENTIFIED BY '你的密码'; GRANT ALL PRIVILEGES ON short_link.* TO 'short_user'@'localhost'; FLUSH PRIVILEGES;然后在 shell 里导入：
mysql -u short_user -p short_link < install.sql接下来生成管理员密码哈希：
php -r "echo password_hash('你的后台密码', PASSWORD_DEFAULT);"把输出的一长串哈希填进 config.php 的admin_pass_hash，再用浏览器打开首页生成一条短链，用 curl 验证跳转是否正常：
curl -I "https://s.example.com/go/ab12Cd"正常情况会看到HTTP/1.1 302 Found和Location: 你的原始长链接这两个关键响应。如果返回 404，优先查 Nginx 的 error.log 和伪静态配置，不要急着怀疑数据库。
5. 踩坑排查与常见问题：404、统计为零、短码撞车怎么定位
5.1 短链访问 404，首页却正常
现象：首页能打开，短链也能正常生成，但点击短链就是 404。
原因：绝大多数是伪静态没生效。Nginx 改完配置没有 reload，Apache 的 mod_rewrite 没启用，或者 AllowOverride 配置为 None 导致 .htaccess 被忽略。另一个可能是 rewrite 规则写错了短码正则，把大小写字母挡掉了。
解决：先绕开伪静态，直接访问go.php?code=ab12Cd。如果这样可以跳转，问题确定在伪静态。Nginx 执行nginx -t && nginx -s reload，Apache 执行sudo a2enmod rewrite后重启。再看一眼 error.log，Nginx 的 rewrite 报错会直接写在那里。最后用curl -I看状态码，302 就是通了。
5.2 点击统计一直是 0
现象：短链能正常跳转，但后台统计数字纹丝不动。
原因：三个常见坑。一是 go.php 里把统计代码放在header('Location: ...')之后，PHP 执行到 header 不代表脚本立刻结束，但如果你接着写了exit，统计代码根本不会执行。二是统计逻辑里用了$_SERVER['HTTP_X_FORWARDED_FOR']而服务器前面没有可信代理，拿到的是空值或伪造值。三是 database 写入失败被 try-catch 吞掉了，页面正常跳转但数据没落库。
解决：先在 config 开 debug，再去后台看是否出现 PDO 异常日志。没有异常就检查代码顺序，统计必须放在 header 之前。IP 获取我一般只用REMOTE_ADDR，如果有 Nginx 反代，在 Nginx 层配置real_ip_header X-Forwarded-For比在 PHP 里盲取更可靠。
5.3 短码偶尔生成失败或突然变长
现象：连着生成几十条都没问题，某一次提示生成失败，或者短码突然变成 7 位。
原因：随机冲突在小规模下概率很低，但并发上来后，两个请求可能同时查到同一个短码「不存在」，然后同时插入，其中一个撞上唯一索引直接报错。生成函数里的重试只覆盖了「查重后发现冲突」的情况，没有捕获数据库唯一索引抛出的异常。另外递归加长逻辑会在 5 次冲突后把短码升到 7 位，这是设计内行为，不算 bug。
解决：在生成函数外层的调用处捕获 PDO 异常，判断错误码是不是 23000（唯一索引冲突），是就重新生成，最多重试 10 次。如果你希望短码长度固定不变，可以把short_len从 6 调到 7，冲突概率指数下降，运维心态也会稳很多。
5.4 后台登录后刷新就掉线
现象：账号密码输对了，登录成功跳回后台，一刷新又回到登录页。
原因：Session 没存下来。最常见是 PHP session 目录不可写，其次是 Cookie 作用域问题——你从s.example.com登录，但后台接口请求的是www.s.example.com，Cookie 匹配不上。还有一种情况是服务器同时支持 HTTP 和 HTTPS，登录时种下的 Cookie 带上了 Secure 属性，换到 HTTP 访问时浏览器就不发这个 Cookie。
解决：检查session.save_path目录权限，确保 Web 用户可写。在登录脚本开头加上：
session_set_cookie_params([ 'secure' => isset($_SERVER['HTTPS']), 'httponly' => true, 'samesite' => 'Lax', ]);这样 Cookie 只在 HTTPS 下标记 Secure，HTTP 下不会因为属性不匹配而失效。同源域名问题则在 config 里统一强制使用带不带 www 的单一域名，并在 Nginx 层把另一个域名 301 跳转过来。
5.5 迁移服务器后老短链全部失效
现象：代码和数据库都搬过去了，旧的短链全部打不开，但新建的短链正常。
原因：迁移后最容易漏三样东西：伪静态配置（Nginx 的规则没有跟着搬迁）、base_url 没改成新域名导致后台展示的短链还是老地址、PHP 扩展没装齐导致 go.php 里 mb_substr 直接报错。
解决：迁移完成后按顺序验证。第一步php -m | grep pdo_mysql确认扩展；第二步直接访问go.php?code=旧短码排除伪静态；第三步看后台列表里的短链前缀是不是新域名。我一般会拿旧的短码用 curl 抽查 10 条，返回 302 且 Location 正确，就说明数据和代码都没问题，剩下只是配置差异。
6. 二次开发实战：给短链系统加一个带鉴权的对外生成 API
如果你不想让运营人员直接接触后台，最常见的改造是把「生成短链」这个动作封装成 API，交给内部系统调用。我在 admin 目录下加了一个 api_create.php，用请求头里的 X-Api-Key 做鉴权：
<?php // admin/api_create.php require __DIR__ . '/../include/db.php'; $config = require __DIR__ . '/../config.php'; $apiKey = $_SERVER['HTTP_X_API_KEY'] ?? ''; if (!hash_equals($config['api_key'], $apiKey)) { http_response_code(401); exit(json_encode(['ok' => false, 'msg' => 'invalid key'])); } $url = filter_var($_POST['url'] ?? '', FILTER_VALIDATE_URL); if ($url === false) { http_response_code(422); exit(json_encode(['ok' => false, 'msg' => 'bad url'])); } $code = create_code($db, $config['short_len']); $stmt = $db->prepare('INSERT INTO sl_links (code, url, status, click_count, created_at) VALUES (?, ?, 1, 0, NOW())'); $stmt->execute([$code, $url]); header('Content-Type: application/json'); echo json_encode([ 'ok' => true, 'short_url' => $config['base_url'] . '/' . $code, 'code' => $code, ]);这里有两个细节值得说。hash_equals做 API Key 比对，避免了普通的==比较带来的时序攻击风险，虽然内部系统不一定遇到攻击者，但养成这个习惯没坏处。FILTER_VALIDATE_URL在 PHP 里对中文字符的容忍度不算高，如果你要处理的链接里带中文参数，可以改成先做 rawurlencode 再校验，或者干脆自己用 parse_url 拆解判断 scheme 和 host。
验证方式也很直接，用 curl 模拟内部系统调用：
curl -X POST "https://s.example.com/admin/api_create.php" \ -H "X-Api-Key: 你的Key" \ -d "url=https://example.com/some/long/path?id=123"返回的 JSON 里带着短码和完整短链，内部系统拿到后直接落库或回传给业务方。如果要继续做限流，常见做法是在生成前检查 Redis 或数据库里同一 IP 最近 1 秒的请求次数，超过阈值直接返回 429，这套逻辑也能挂在 api_create.php 里复用。这次改造让我养成了一个习惯：动跳转逻辑之前，先用 curl 把「旧短链 302、失效短链 404、停用短链 410」三条用例各跑一遍，确认状态码没变才继续往上加功能。后来有次我改完统计逻辑忘了看返回头，运营反馈说点不动，排查半天发现是统计查询超时把跳转拖死了。从那以后，每次改完代码我都强制走一遍 curl 全链路验证再交付，希望帮到你。
本文还有配套的精品资源，点击获取
