短链接无法直接还原，仅自建系统且保留映射关系时才可行；需通过数据库查询或结构化日志回溯，而非依赖重定向或函数解码。
短链接本身不自带还原能力，PHP 无法直接“解码”任意第三方短链（如 t.cn、bit.ly），所谓“还原”只在你自建短链系统且保留原始 URL 映射关系的前提下才可行。核心不是调用某个函数，而是查数据库或日志。
为什么
或
不能可靠还原短链？
HTTP 重定向（301/302）返回的是最终跳转目标，但很多短链服务做了反爬或限流：返回 403、429、空白页，甚至故意返回首页或错误页。更关键的是，部分短链（如
微信
内
协议、
企业微信
私有短链）根本不会在服务端暴露真实地址，只在客户端 SDK 解析。
依赖重定向会漏掉协议级拦截（如 UA 检查、Referer 校验）
高频请求触发风控，返回非真实跳转地址
无法处理带参数签名、时效性 Token 的短链（如阿里云 OSS 临时链接）
自建短链系统中，如何从日志还原原始 URL？
前提是你的短链跳转逻辑写入了访问日志（推荐结构化日志），而不是只记录 Apache/Nginx 默认
access
_log。关键字段必须包含：
、
、
、
（可选）。
例如使用 PHP 写入 JSON 日志：
PHP 8.5.5
PHP 8.5.5 是 PHP 8.5 分支的维护更新版本。该版本延续了“小步快跑”的迭代逻辑，通过深度错误修复、底层性能微调以及安全加固，旨在为开发者提供一个更健壮、更高效的运行环境。该版本严格遵守语义化版本规范，不包含破坏性变更。
下载
立即学习
“
PHP免费学习笔记（深入）
”；
不要依赖 Nginx 日志里的
—— 它不含重写后的真实映射
日志需在
之前写入，避免因跳转中断导致丢失
若用 Redis 缓存映射，记得同步写日志，否则缓存过期后无法追溯
从数据库直接查原始 URL（最可靠方式）
只要短码生成时存了映射，还原就是一次简单查询。重点是表结构设计和索引：
查询语句必须用
，别用
或模糊匹配
如果支持大小写混合（如
），字段定义要加
高并发场景下，
和
建议合并为原子操作（如 MySQL 的
）
真正难的不是“怎么查”，而是日志或数据库里压根没存原始 URL —— 比如用了纯算法生成（Base62
编码
ID）、没持久化映射、或把原始链接存在外部不可审计的存储里。这种情况下，没有回溯路径，任何 PHP 函数都无能为力。
file_get_contents()cURLweixin://short_codeoriginal_urltimestampipfile_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);$request_uriheader("Location: ...")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 = ?LIKEaB3xCOLLATE utf8mb4_binUPDATE hitsSELECT original_urlINSERT ... ON DUPLICATE KEY UPDATE