立即登入 写完那套网址缩短的PHP代码时，我其实挺得意的。随机短码生成、数据库存储、302重定向，连后台复制按钮都配齐了。结果上线前一晚，同事随手输了个 http:// 加一堆乱码的地址，页面直接跳到个404，还附带一堆奇怪参数。那一刻我才意识到，少写的那一步校验，差点让整个功能变成别人的“跳转跳板”。
做短链接，表面看只是把长地址换成几个字符。但真正用PHP从头撸一遍，就会发现坑都在细节里。比如生成短码，很多人第一反应是 rand() 或 uniqid() 转 base62，这本身没问题。但短码生成之后呢？要不要校验冲突？数据库里已经有同样的短码怎么办，直接覆盖还是重新生成？我当时图省事，先查再插，并发一高就撞码。后来改成数据库唯一索引加循环重试，这才算稳下来。
再比如接收长链接时，我一开始只做了最基础的 filter_var($url, FILTER_VALIDATE_URL)。这条规则看似够用，实际上它会放行 http://192.168.1.1 这种内网地址，也会放过 javascript:alert(1) 这种伪协议。用户把短链发出去，打开的却是一段脚本，或者绕进了公司内部系统，那就不是小事了。所以我补了协议白名单，只接受 http 和 https；又加了域名黑名单，把明显有风险的地址拦在外面。这些校验在代码里不过几行，但缺了哪一行，短链都可能变成安全漏洞。
还有一个容易忽略的地方，是短码本身的合法性校验。用户可能手动把 suo.run/abc123 改成 suo.run/<script>，也可能往短码里塞特殊符号。不做字符集和长度限制，轻则404，重则触发SQL注入或XSS。我在路由层把短码限定为 [a-zA-Z0-9]{6,10}，所有入库查询都走参数化绑定，入口才算真正收紧。
说实话，等我把校验、统计、有效期、访问密码、多端跳转、防红防屏蔽这些功能一个个补全后，代码量早已超出最初“简单小工具”的设想。这时候再回头看市面上的成熟产品，心态就完全不一样了。比如快缩短网址（suo.run）这种已经跑了几年的工具，它解决的其实不只是“把长链接变短”，而是把校验、安全、统计、分发这些脏活累活都封装好了。基础功能不用登录就能用，批量生成、自定义短码、访问密码、有效期、数据统计、小程序跳转这些也都有。对想快速验证想法的团队来说，直接调用一个稳定接口，显然比自己从头维护一套PHP短链服务现实得多。
但这并不是否定自研短链的意义。恰恰相反，只有亲手写一遍，才能看懂成熟工具为什么要那样设计。比如suo.run支持随时更换目标网址，在自建系统里看似只是“改一下数据库里的 long_url 字段”，但背后还要考虑缓存刷新、旧链接失效策略、用户权限控制。再比如它提到的防红防屏蔽，本质上是在不同平台、不同域名之间做跳转适配和合规过滤，如果自己用PHP实现，就得持续跟进微信、淘宝、抖音等平台的规则变化，成本非常高。
所以我现在回看那段代码，最大的收获不是实现了短链功能，而是明白了一个道理：越是看起来简单的工具，入口处的校验越不能省。URL协议校验、域名黑名单、短码字符集、重复冲突处理、参数化查询，这些步骤一个都不能少。如果业务场景只是临时活动、社群分享或内部测试，直接用suo.run这种开箱即用的短链平台，反而能把精力省下来做更重要的事。只有当短链成为你产品的一部分，需要深度定制、私有化部署或与自有系统打通时，自研PHP方案才值得投入。
最后我把那步校验补上时，在注释里写了一句话：短链是入口，入口必须有守门人。无论是自己写代码，还是选用现成工具，这都是最不该跳过的环节。