你盯着浏览器地址栏里那串字符，网站.html、扩展.php、网站.aspx，扩展像某种远古生物的网站尾巴。多数人一辈子不会点开它们，扩展但网站能不能跑起来，网站全看这条尾巴甩得对不对。扩展

扩展名本质上是网站文件格式的身份证。服务器收到请求，扩展先瞄一眼这串后缀，网站再决定用哪套工具去解析。扩展你访问example.com/page.html，网站服务器直接把文件丢给浏览器；换成page.php，扩展就得先让PHP引擎把代码嚼一遍，网站吐出纯HTML再送出去。同样的内容，后缀不同，背后的处理流程天差地别。

有个老笑话：把Word文档改名成.exe，双击后电脑会骂你。网站这边更微妙——你没法靠改后缀让PHP文件变成图片，但服务器配置能强行指定“哪怕后缀是.jpg，也按PHP执行”。早年有些站点上传图片时没检查内容，黑客传个shell.jpg，里面藏着PHP代码，服务器傻乎乎地执行了，整台服务器就归人家了。后来大家学乖了，要么检查文件头，要么干脆把上传目录的脚本执行权限关掉。

扩展名不是越多越好。我见过某个老项目，URL里带着.do、.action、.json三种尾巴，分别对应不同年代的框架。后来维护的人疯了，新接口全改成/api/xxx这种无后缀路径，用请求头里的Accept字段区分返回格式。这叫“伪静态”——服务器重写规则把/article/123映射到article.php?id=123，地址栏干净了，用户看着舒服，搜索引擎也喜欢。

但别急着全扔掉扩展名。有些场景它反而是救命的。比如下载文件时，服务器得告诉浏览器“这是.zip，别当HTML打开”，靠的就是Content-Type头，跟URL后缀没关系。可一旦服务器配置错乱，把.pdf当纯文本输出，浏览器界面全是乱码，用户只会骂网站烂，不会怪自己没装阅读器。

我自己踩过坑。有次给客户做站点，图片存在CDN上，URL末尾没扩展名。结果某个老旧的Windows服务器死活不肯缓存这些文件，流量费用翻了三倍。后来在URL后面加了个.jpg，问题立刻消失——那台服务器的缓存策略只认后缀，不认内容。你说荒唐不荒唐？但现实就是这样，技术决策经常被历史包袱绑架。

现在主流框架早就不靠扩展名干活了。RESTful API里/users/42就是获取用户，返回JSON还是XML由请求头决定。但浏览器地址栏里那些静态资源——CSS、JS、图片——还是老老实实带着后缀。为什么？因为HTTP缓存、CDN回源、服务器压缩模块，全都默认按扩展名匹配规则。你硬要特立独行，就得手动配一堆MIME类型映射，纯属给自己找麻烦。

扩展名这东西，像老房子里的承重墙。你看不见它，但它撑着整个结构。哪天你心血来潮想拆掉，得先确认楼上没人住。网站开发也一样，你可以用无后缀的漂亮URL，但底层总得有个地方告诉服务器“这请求该交给谁处理”。这个“地方”，要么是扩展名，要么是路由表，要么是中间件——本质上都是给文件或请求贴标签。

说到底，扩展名只是约定俗成的标签系统。它不完美，容易被伪造，也引发过安全漏洞。但它的价值在于：让服务器、浏览器、CDN、缓存层这些不同年代的软件，用最简单的方式达成共识。就像马路上的路标，你可以用GPS导航，但路标永远不会消失——因为总有人没装GPS，也总有GPS失灵的时候。

(责任编辑：知识)