3月3日，一位開發(fā)者在午餐前把域名改了3次。6次提交，2次回滾，生產(chǎn)環(huán)境炸了15分鐘——這不是什么史詩(shī)級(jí)故障，是Firebase Hosting的常規(guī)操作。

問(wèn)題出在大多數(shù)人沒(méi)讀完文檔的那個(gè)章節(jié)。

claude-code-plugins（后文稱CCP）是個(gè)開發(fā)者工具市場(chǎng)，域名claudecodeplugins.io用了段時(shí)間。品牌升級(jí)要切到tonsofskills.com，按開發(fā)者估算，20分鐘搞定。實(shí)際耗時(shí)：一上午，外加兩次生產(chǎn)回滾。

第一次嘗試（提交1-2）：firebase.json里同時(shí)配兩個(gè)域名，舊域名301到新域名。部署，完成，收工。

Firebase沒(méi)按劇本走。

兩個(gè)域名，一個(gè)陷阱

Firebase Hosting的多域名配置有個(gè)隱藏規(guī)則：firebase.json里hosting targets的順序決定canonical domain（規(guī)范域名）。開發(fā)者把tonsofskills.com放第一、claudecodeplugins.io放第二，F(xiàn)irebase確實(shí)把前者認(rèn)作主域名——但后者的"重定向"根本不是重定向。

兩個(gè)域名同時(shí)解析到同一份內(nèi)容。沒(méi)有301狀態(tài)碼，沒(méi)有canonical標(biāo)簽，就是兩套一模一樣的站點(diǎn)在搜索引擎里互相搶排名。

DNS propagation（域名傳播）雪上加霜。新域名已上線但未全球同步，部分用戶訪問(wèn)舊域名能打開，部分訪問(wèn)新域名遇到證書錯(cuò)誤——SSL證書還沒(méi)簽發(fā)完。15分鐘窗口期，兩個(gè)域名都不穩(wěn)定。

這時(shí)候沒(méi)有"再試一次"的選項(xiàng)?；貪L，全部回滾，回到已知可用的狀態(tài)。

提交3和4是連續(xù)兩次revert（回滾）。生產(chǎn)環(huán)境。當(dāng)著用戶的面。

第三次才摸到的正確姿勢(shì)

提交5的關(guān)鍵洞察：不要試圖讓兩個(gè)域名共享一個(gè)hosting target（托管目標(biāo)）。給舊域名單獨(dú)建一個(gè)redirect target（重定向目標(biāo)），返回301指向新域名。沒(méi)有共享配置，沒(méi)有canonical歧義。

提交6完成最終形態(tài)：tonsofskills.com作為唯一主域名，獨(dú)立hosting target；舊域名純301跳轉(zhuǎn)，不托管任何內(nèi)容。

Firebase Hosting的redirect rules（重定向規(guī)則）和custom domain configuration（自定義域名配置）是兩個(gè)系統(tǒng)。firebase.json里的redirects字段只處理單域名內(nèi)的路徑跳轉(zhuǎn)，跨域名的canonical重定向必須在hosting target層面配置——或者干脆用專門的跳轉(zhuǎn)目標(biāo)。

別在多域名配置上耍小聰明。一個(gè)hosting target對(duì)應(yīng)一個(gè)域名，其他全部301走。

同一天的其他交付倒是干凈利落：首頁(yè)全量 redesign（重新設(shè)計(jì)）成暗色主題，對(duì)齊Braves Booth的視覺風(fēng)格；/research頁(yè)面上線，塞了6份數(shù)據(jù)分析文檔；全站埋了UTM tracking（UTM追蹤）和完整的事件埋點(diǎn)；hero區(qū)域加了行小字"by intent solutions io"。

唯獨(dú)域名遷移這塊骨頭，反復(fù)啃了三遍才咽下去。

開發(fā)者把完整commit序列曬了出來(lái)。提交3和4那兩道回滾痕跡，比任何教程都誠(chéng)實(shí)。

Firebase官方文檔其實(shí)寫了這些區(qū)別，但藏在"配置多個(gè)域名"章節(jié)的折疊列表里。大多數(shù)人看到"添加自定義域名"的按鈕就停下了，沒(méi)往下翻那三段關(guān)于canonical行為的警告。

這個(gè)坑的詭異之處在于：配置看起來(lái)工作正常。兩個(gè)域名都能打開，內(nèi)容一致，沒(méi)有報(bào)錯(cuò)。直到你查HTTP狀態(tài)碼，或者發(fā)現(xiàn)搜索排名莫名其妙地掉，才意識(shí)到哪里不對(duì)。

Google Search Console里會(huì)出現(xiàn)"重復(fù)內(nèi)容"警告。兩個(gè)域名沒(méi)有canonical關(guān)系，搜索引擎把它們當(dāng)獨(dú)立站點(diǎn)處理，流量被稀釋。對(duì)于依賴自然搜索的工具類產(chǎn)品，這是慢性失血。

開發(fā)者的第二次嘗試（提交5）仍然不是最優(yōu)解，但方向?qū)α?。把redirect獨(dú)立成一個(gè)hosting target，相當(dāng)于給舊域名辦了"注銷戶口"，所有流量強(qiáng)制遷到新地址。這時(shí)候即使DNS還沒(méi)完全同步，用戶至少不會(huì)被丟到錯(cuò)誤頁(yè)面。

SSL證書的問(wèn)題另有一套機(jī)制。Firebase Hosting的證書是自動(dòng)申請(qǐng)的，但propagation期間可能出現(xiàn)"證書域名不匹配"的錯(cuò)誤。這時(shí)候除了等，沒(méi)有捷徑。但把舊域名設(shè)為純跳轉(zhuǎn)后，至少用戶訪問(wèn)舊地址能被301到新地址，而不是直接報(bào)錯(cuò)。

那天的其他交付

域名 chaos（混亂）之外，3月3日的產(chǎn)出密度不低。

Braves Booth是開發(fā)者的另一個(gè)項(xiàng)目，暗色主題+高對(duì)比度排版。CCP首頁(yè) redesign 完全對(duì)齊這套視覺語(yǔ)言，產(chǎn)品矩陣感出來(lái)了。

/research頁(yè)面放了6份文檔，主題涵蓋插件市場(chǎng)分析、開發(fā)者工具趨勢(shì)、技能圖譜數(shù)據(jù)。每份都有原始數(shù)據(jù)支撐，不是觀點(diǎn)合集。

UTM tracking和事件埋點(diǎn)用的是Firebase Analytics + BigQuery的默認(rèn)集成。全站點(diǎn)擊、頁(yè)面停留、轉(zhuǎn)化漏斗，全部可追蹤。對(duì)于工具類產(chǎn)品，這是后期優(yōu)化的基礎(chǔ)設(shè)施。

hero區(qū)域的"by intent solutions io"是品牌歸屬聲明。小字，不搶視覺，但法務(wù)和商務(wù)場(chǎng)景需要。

這些全部一次過(guò)。唯獨(dú)域名，回滾兩次。

開發(fā)者在復(fù)盤里寫了一句：「Nothing teaches you Firebase Hosting like renaming your domain three times before lunch.」

翻譯過(guò)來(lái)：沒(méi)什么比午餐前改三次域名更能教你用Firebase Hosting了。

這是典型的工程師黑色幽默。代價(jià)是真實(shí)的——15分鐘服務(wù)不穩(wěn)定，兩次生產(chǎn)回滾，一上午的上下文切換。但收獲也是真實(shí)的：一套經(jīng)過(guò)驗(yàn)證的域名遷移SOP（標(biāo)準(zhǔn)操作流程），以及一篇比官方文檔更誠(chéng)實(shí)的踩坑記錄。

Firebase Hosting不是唯一有這類陷阱的服務(wù)。Vercel的redirect配置也有類似的"隱式行為"，Netlify的_edge functions（邊緣函數(shù)）在域名層面的處理同樣需要仔細(xì)測(cè)試。靜態(tài)托管服務(wù)都把"簡(jiǎn)單"寫在首頁(yè)，但魔鬼在multi-domain（多域名）的細(xì)節(jié)里。

對(duì)于CCP這類開發(fā)者工具市場(chǎng)，域名是信任錨點(diǎn)。claudecodeplugins.io聽起來(lái)像side project（副業(yè)項(xiàng)目），tonsofskills.com更接近可持續(xù)業(yè)務(wù)的命名。品牌升級(jí)的決策沒(méi)錯(cuò)，執(zhí)行層面的學(xué)費(fèi)交得有點(diǎn)貴。

開發(fā)者把完整時(shí)間線開源出來(lái)，包括錯(cuò)誤的提交序列。這種透明在開發(fā)者社區(qū)是硬通貨——比 polished（ polished ）的案例研究更有參考價(jià)值。

同一天，Braves Booth Intelligence（開發(fā)者的另一個(gè)項(xiàng)目）也在推進(jìn)。3月3日確實(shí)是heavy day，但 heavy 的方式和預(yù)期不太一樣。

Firebase的文檔團(tuán)隊(duì)后來(lái)更新了相關(guān)章節(jié)，把canonical domain的行為提到了更顯眼的位置。但文檔永遠(yuǎn)追不上真實(shí)世界的排列組合。兩個(gè)域名、兩種配置順序、三種可能的SSL狀態(tài)，乘起來(lái)就是12種需要測(cè)試的場(chǎng)景。

開發(fā)者的最終配置很簡(jiǎn)單：一個(gè)hosting target，一個(gè)域名，其他全部301。這種"過(guò)度簡(jiǎn)化"恰恰是經(jīng)過(guò)復(fù)雜試錯(cuò)后的收斂。

對(duì)于正在規(guī)劃域名遷移的技術(shù)負(fù)責(zé)人，這個(gè)案例的 takeaway（要點(diǎn)）很具體：測(cè)試環(huán)境復(fù)刻生產(chǎn)環(huán)境的域名配置，包括DNS和證書狀態(tài)；準(zhǔn)備回滾方案，不是"有問(wèn)題再回滾"，是"默認(rèn)會(huì)出問(wèn)題"；canonical行為用curl -I驗(yàn)證，不要只看瀏覽器能不能打開。

3月3日的commit歷史現(xiàn)在成了公開教材。提交3和4那兩道回滾，比任何"最佳實(shí)踐"標(biāo)題都更有說(shuō)服力。

當(dāng)你下次看到"簡(jiǎn)單配置，即刻上線"的產(chǎn)品標(biāo)語(yǔ)時(shí)，會(huì)多留個(gè)心眼嗎？