短链接无法直接还原，仅自建系统且保留映射关系时才可行；需通过数据库查询或结构化日志回溯，而非依赖重定向或函数解码。
短链接本身不自带还原能力，PHP 无法直接“解码”任意第三方短链（如 t.cn、bit.ly），所谓“还原”只在你自建短链系统且保留原始 URL 映射关系的前提下才可行。核心不是调用某个函数，而是查数据库或日志。
为什么 file_get_contents() 或 cURL 不能可靠还原短链？
HTTP 重定向（301/302）返回的是最终跳转目标，但很多短链服务做了反爬或限流：返回 403、429、空白页，甚至故意返回首页或错误页。更关键的是，部分短链（如微信内 weixin:// 协议、企业微信私有短链）根本不会在服务端暴露真实地址，只在客户端 SDK 解析。
- 依赖重定向会漏掉协议级拦截（如 UA 检查、Referer 校验）
- 高频请求触发风控，返回非真实跳转地址
- 无法处理带参数签名、时效性 Token 的短链（如阿里云 OSS 临时链接）
自建短链系统中，如何从日志还原原始 URL？
前提是你的短链跳转逻辑写入了访问日志（推荐结构化日志），而不是只记录 Apache/Nginx 默认 access_log。关键字段必须包含：short_code、original_url、timestamp、ip（可选）。
例如使用 PHP 写入 JSON 日志：
立即学习“PHP免费学习笔记（深入）”；
file_put_contents('/var/log/shortlink/access.log', json_encode([
'short_code' => $_GET['s'] ?? '',
'original_url' => $db->fetchOriginalUrl($_GET['s']),
'timestamp' => date('c'),
'ip' => $_SERVER['REMOTE_ADDR']
]) . "\n", FILE_APPEND);
- 不要依赖 Nginx 日志里的
$request_uri—— 它不含重写后的真实映射 - 日志需在
header("Location: ...")之前写入，避免因跳转中断导致丢失 - 若用 Redis 缓存映射，记得同步写日志，否则缓存过期后无法追溯
从数据库直接查原始 URL（最可靠方式）
只要短码生成时存了映射，还原就是一次简单查询。重点是表结构设计和索引：
CREATE TABLE `short_urls` ( `id` BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT, `short_code` VARCHAR(8) NOT NULL, `original_url` TEXT NOT NULL, `created_at` TIMESTAMP DEFAULT CURRENT_TIMESTAMP, `hits` INT DEFAULT 0, INDEX `idx_short_code` (`short_code`) );
- 查询语句必须用
WHERE short_code = ?，别用LIKE或模糊匹配 - 如果支持大小写混合（如
aB3x），字段定义要加COLLATE utf8mb4_bin - 高并发场景下，
UPDATE hits和SELECT original_url建议合并为原子操作（如 MySQL 的INSERT ... ON DUPLICATE KEY UPDATE）
真正难的不是“怎么查”，而是日志或数据库里压根没存原始 URL —— 比如用了纯算法生成（Base62 编码 ID）、没持久化映射、或把原始链接存在外部不可审计的存储里。这种情况下，没有回溯路径，任何 PHP 函数都无能为力。
