AI 篤定說 CSP 的 style-src unsafe-inline 拿不掉，我追問一句後它道歉了
2026-06-01 早上，甲方把一份 ZAP 弱掃報告丟過來，四條中風險全是 CSP（Content Security Policy，瀏覽器用來限制頁面能載入哪些來源的一層 HTTP header 防護）相關，附帶一句「中風險都要修」。最難纏的一條是 style-src 'unsafe-inline'。 我把報告丟給 Claude Code，請它評估。那天它給的結論是：這條技術上修不乾淨，只能寫一封信去說服甲方接受。兩天後，我們把它從正式機完全拿掉了，全站 94 個頁面實測零影響。 中間發生的事，比結論本身有意思——因為它一開始錯得很徹底，而我差點就照單全收了。 先搞清楚 V3 到底還剩幾條Claude Code 先把我們 Vue 3 專案正式機的 Web.config 拉出來對。弱掃報告裡那串髒兮兮的 CSP 其實是同台 server 上舊版 AngularJS 站台的，不是 V3 的。V3 的狀況比我以為的好： 1234script-src 'self' 'wasm-unsafe-eval'style-src &#x...
Pinia 還是 Vuex？Vue 3 新專案與舊系統怎麼選
這篇舊稿原本把 Pinia 寫成「也支援 Vue 2」，還用 tree-shaking 和一組沒有來源的體積數字來分勝負。到了 2026 年，前一句已經過時，後一句也把幾個不同概念混在一起。 先講我的選擇：新開的 Vue 3 專案直接用 Pinia。既有 Vuex 專案是否搬遷，則看 Vue 版本、外掛依賴與測試覆蓋率，沒必要為了跟上推薦名單就整批重寫。 官方定位已經很清楚Pinia 官方介紹說明，它在 2019 年從 Composition API 的 store 實驗開始，後來吸收 Vuex 5 討論中的想法，最後成為 Vue 官方推薦的狀態管理方案。 Vuex 沒有因此突然失效。Vuex 3 對應 Vue 2，Vuex 4 對應 Vue 3，既有系統仍可以維護；只是新專案沒有太多理由再背 mutation、巢狀 module 與額外的 TypeScript 包裝。 還有一個版本陷阱：Pinia 最新主線只支援 Vue 3。需要 Vue 2 的專案得留在 Pinia v2 分支，不能把「Pinia 曾支援 Vue 2」寫成「最新版仍支援」。 mutation 為什麼消失了？V...
