這個程序員把網址里的問號禁了

　　周三下午，Chris Morgan 坐在電腦前，盯著一串帶問號的鏈接。https://chrismorgan.info?utm_source=twitter&utm_medium=social——這種網址他見多了。別人往他的鏈接里塞跟蹤參數，像在給網頁打標記。他決定：在自己的網站上，問號后面不許跟任何東西。

　　Morgan 不是技術小白。他的個人網站跑在 Caddy 服務器上，自己寫配置。這次他加了一條規則：所有帶查詢字符串的請求，一律拒絕。所謂查詢字符串，就是網址里問號后面的部分——?t=123、?utm_source=xxx 都算。他的邏輯很直接：Referer 請求頭已經能告訴我流量從哪來，不需要你再畫蛇添足。如果 Referer 為空，那通常有正當理由，我更不該強行追蹤。

　　這種做法在技術上不算復雜。Morgan 在 Caddyfile 里加了攔截規則，測試了幾種邊界情況。他原本想直接把這篇文章發布在 https://chrismorgan.info/?，也就是路徑為空、查詢字符串也為空的極端 URL。這會打破很多工具的假設——curl 命令行甚至會非法截斷尾部的問號。但他最終選擇了仁慈：用 /no-query-strings 作為文章地址，放過那些沒做錯的普通人。

　　這不是一時興起。Morgan 提到，早年他確實用過 ?t=… 和 ?h=… 來給樣式表做緩存破壞。現在他認定這些用法可以中斷，網站上不應該再有合法的查詢字符串請求。如果有人非要試試加參數會怎樣，服務器會禮貌地拒絕。這是他對自己域名主權的宣示：我的網址，我做主。

　　這件事的有趣之處在于反向思考。整個行業都在追逐更精細的追蹤——UTM 參數、點擊熱圖、用戶畫像——Morgan 卻在做減法。他不反對別人在自己的網站上用這些工具，但反感別人把這些東西塞進他的鏈接里。UTM 參數本該是內容創作者自己用的，不是讓讀者幫你填的。這種"越界"讓他不適。

　　技術實現上有個小插曲。Morgan 承認自己在折騰 Caddy 的極限：try_files 重寫 involved 時服務器會卡住。他猜以前沒人用 Caddy 干過這種"蠢事"。這反而讓他更來勁——反正已經在 push Caddy 的邊界了，不妨再推一把。他計劃以后用 /? 或 /%3F（編碼后的問號）做點別的實驗。

　　這件事能引發討論，是因為它戳中了一個灰色地帶。追蹤參數是行業慣例，但慣例不等于正確。Morgan 的解決方案是技術性的，但他的出發點很產品化：用戶體驗。普通用戶看到一串 UTM 參數，不會覺得專業，只會覺得亂。更重要的是，這是他的網站，他有權利定義什么是"干凈"的鏈接。

　　最后他留了一句話：你可以對你的網站做任何事。這是開源精神，也是互聯網的原教旨主義——每個域名都是一塊自治領地。Morgan 選擇用代碼劃定邊界，而不是寫篇文章抱怨。這種動手解決問題的風格，比他的觀點本身更值得注意。