時刻

開啟 VPN 中的系統代理後，本地測試域名（比如 *.test）突然打不開了？

錯誤動作：在代理軟體裡加 DIRECT（直連）規則。

這是沒用的！因為流量一旦進入代理軟體，它就會用公共 DNS 去查這個本地域名，查不到 IP 直接就報錯攔截了。

正確姿勢：在作業系統的「網路設定 → 代理忽略名單（Bypass）」裡添加 *.test（或者在代理軟體裡配置 Bypass 繞過名單）。

核心原理：

流量最先是由作業系統接收到的。

Bypass（繞過）：流量根本不進代理軟體，作業系統自己處理，用本機 DNS 直接訪問。

DIRECT（直連）：流量已經進了代理軟體，代理軟體去嘗試直連，但通常會死在 DNS 解析上。

這個問題不是第一次遇到，也都能解決，但是今天是第一次搞明白了。

“手工參與代碼的感覺真好，不讓 AI 代替自己寫代碼的感覺真好。”

剛才試了一下新的全局 Cursor 規則，自己參與功能思考，關注代碼組織和質量，全身心參與的感覺又回來了。

為了讓自己能夠參與到程式碼組織和編寫的過程中，我給 cursor 添加了幾條全域規則：

1. 幫我設定一下全域 cursor rules，添加一條，只需要給出方案、計劃，或者每一步的實現代碼，不要替我寫。

2. 提交資訊中不要有 Co-authored-by。

3. 另一個規則：為更改寫提交訊息，不要提交。我會手動提交。

今天把這個站點添加到了 bing 和 yandex。

接下來可以觀察和熟悉這些搜索平台的功能和特點。

隨著網站內容變多，Nextjs SSG build 的時間也變長了。

之前的考量是：預渲染頁面，少使用 SSR，讓頁面開啟速度變快。最近部署的時候，發現等待的時間變長了，主要卡在 nextjs build 這裡。

問了一下 AI，AI 根據問題和網站場景，幫我做了分析。看過 AI 的回答和思考之後，我把 SSG 去掉了，只使用 SSR。這樣就又回到了 PHP、Rails 等傳統服務的路子。服務端渲染 + 快取，感覺清爽多了。部署和頁面訪問的速度都沒有問題。

隨著實踐，能夠感受到：技術運用應該是隨著問題的出現和解決而使用的，沒有標準答案。

React Native 的開發體驗挺不錯的。

雖然現在很多人都在用 AI 來做 vibe coding，但是經過一段時間的重度實踐，我的觀點反而是：作為工程師，還是需要保持技術學習，理解和掌握。

不太忙的時候，靜下心看看技術書籍。這個過程中，會感到自己的理解力增加了。一些沒有注意過，或者不太紮實的地方，都會得到補充。

循序漸進的教程，會讓人很容易專注投入進去。寫教程的過程中，對於知識的拆解和編排，也是一種很強的能力。

function Echo() {
  const params = useParams();
  const [searchParams] = useSearchParams();
  return <h1>{params.msg || searchParams.get("msg")}</h1>;
}

const param = "From Param";
const query = new URLSearchParams({ msg: "From Query" });

export default function App() {
  return (
    <section>
      <p>
      </p>
      <Link to={'echo/${param}'}>Echo param</Link>
       <p>
       </p>
    </section>
    <Link to={'echo?${query.toString()}'}>Echo query</Link>
  );
}

Rybbit - 一個開源且注重隱私的 Google Analytics 替代方案，使用體驗更加直觀易懂，足足提升 10 倍。

讓 Codex 幫我在 RN VPS 上自託管了這個服務，同時接入了現在這個網站。這種工作量，在 Codex 之前是不敢想像的，不是困難和複雜，是在安裝軟體和配置環境上，太折騰了。現在幾分鐘就自動搞定了，我打個下手，就添加一條 domain A 記錄而已。

fumadocs.dev，一個漂亮、靈活，適用於任何 React.js 專案的文件框架。

前幾天，我嘗試用 Ollama 搭配本地的 Qwen 3.5:4b 模型來翻譯一本 PDF 電子書。翻譯速度倒是不成問題，但最後生成的排版效果很糟糕。我的流程是先把 PDF 轉成 Markdown，翻譯後再生成新 PDF，但新 PDF 中的中英文排版上下對照，閱讀起來非常費勁，很不舒服。

後來我查了一下這個問題，發現 PDF 文字排版確實不好處理。不同的書籍、不同的內容都有各自適合的呈現方式，若要針對每本書去調整和優化排版，這個成本實在太高了。

最後我發現 HTML 才是最合適的方案，排版輕鬆就能做到美觀，而我的目標也只是翻譯後能舒服地閱讀。按照這個方案，之後我再找時間繼續完善，用來自學英文書。