编程

阿珏Blog十周年活動已經圓滿結束了。 今年參加的人比我預想中還要多，活動期間經常能看到大家在群裡討論線索、交換提示，也有不少人一路順利通關，拿到了最後的獎勵。看到自己折腾了這麼久(2年前就開始策劃)的東西真的有人認真玩完，還是挺開心的，雖然過程有ai的輔助。 如果你還沒有玩過，建議先去看看活動原文，這篇會直接公開全部答案，下面就是完整劇透，遊戲過程中會有許多颠覆你認知的知识內容。 先說一下整體流程 拆彈專家 → 點擊入口 → 調整黑圖 → 登錄與驗證碼 → 假 Cloudflare 頁面 → PDF 藏 ZIP → GalGame對話找線索 → 猜數字 → 扫描二維碼 → 找不同 → 明暗模式畫冊 → 拼圖 → 保险箱。 第 0 閘：拆彈專家 第一關實際上是一個小小的前奏。頁面上有四根不同顏色的線和一個倒計時，看起來像是要認真判斷哪一根能拆掉炸彈。 但這裡沒有正確答案，剪哪一根都會爆。爆炸以後，頁面會提示珍藏圖冊已經被炸成碎片，同時收集碎片。 接下來要做的事情也就很明確了：引出支線任務，把散落在後面關卡裡的拼圖碎片找回來。 所以這裡不用在四根線上浪費時間，直接剪一根看爆炸效果就行。 第 1 間：活動歡迎入口 正式進入活動入口頁，畫面中間的“立即參與”按鈕並不是普通的跳轉按鈕，而是通過圖片熱點區域實現的。看到圖片上的手形光標，直接點擊對應位置，就會進入下一關。這一關考驗的是觀察力，也順便用了一下 HTML 圖片熱點區域這種比較老但依然好用的功能。 點擊之後頁面會先變黑，再跳到一個看起來像是加載卡住的頁面。這個黑屏不是加載失敗，耐心看一會兒就能发现问题。 第 1.5 間：黑屏加載中 頁面看起來幾乎是一片黑。這裡沒有必要查看複雜的源代碼，直接把頁面截圖放進圖片編輯器，調整曝光、陰影和對比度就可以了。目的也很直接，就是考驗大家處理圖片、調整曝光和觀察低對比度信息的能力。 調亮之後能看到兩個重要信息： 邀請碼：blog10years 下一關：/level/googleLogin/login.html 第 2 間：登錄頁 登錄頁需要用戶名、密碼和邀請碼。用戶名可以自己填，邀請碼就是上一關找到的 blog10years。 真正麻煩的是密碼。打開開發者工具，在 Console裡可以看到頁面已經定義好的 buildLoginHash 函數。直接調用它即可： ...

規則： 保持 Markdown 結構。 不翻譯 URL 和代碼。 只返回翻譯內容，不附加評論。 # MoeKoe Music Mobile 一款開源、簡潔、高顏值的第三方酷狗音樂移動端播放器 基於 Expo / React Native 构建而成，是 [MoeKoeMusic](https://github.com/iAJue/MoeKoeMusic) 桌面版的移動端實現 🌎 GitHub 存儲庫 | 📦️ 下載安裝包 | 💬 访問博客 | 🏠 專案首頁 一款開源、簡潔、高顏值的第三方酷狗音樂移動端播放器 基於 Expo / React Native 构建而成，是 MoeKoeMusic 桌面版的移動端實現 ✨ 特性 🎵 無需自建伺服器 — 酷狗 API 适配層直接直連官方，開箱即用，不依賴外部 API 地址 🏠 首頁推薦 — 每日推薦、精選歌單、排行榜 🧭 發現頁 — 分類歌單、新歌速遞等內容探索 🔍 搜索 — 快速檢索歌曲、歌單、專輯 📀 歌單 / 專輯 / 排行榜 — 完整的詳情頁與曲目列表 🎧 播放器 — 滾動歌詞、播放隊列、迷你播放條（MiniPlayer）、後台播放 🎚️ 音質檢測 — 自動探測並選擇可用音質 📱 手機號登錄 — 同步酷狗賬號的收藏與歌單 🌗 深色模式 — 跟隨系統自動切換明暗主題 📝 Todo List [x] 首頁每日推薦 / 精選歌單 / 排行榜 [x] 發現頁分類內容瀏覽 [x] 搜索歌曲、歌單、專輯 [x] 歌單 / 專輯 / 排行榜詳情頁 [x] 播放器：滾動歌詞、播放隊列、迷你播放條、後台播放 [x] 音質檢測與自動選擇 [x] 手機號登錄 [x] 賬號密碼登錄 [x] 扫描登錄(其他設備) [x] 我喜歡 / 收藏同步 [x] 用戶歌單管理（創建 / 收藏 / 編輯） [ ] 通知欄 / 锁屏播放控制 [ ] 歌曲詳情瀏覽 [ ] 桌面歌詞 [ ] 聽歌識曲 [ ] 平板與橫屏適配 [ ] 性能優化 📸 預覽 🚀 快速開始 環境要求 Node.js ≥ 22 Git iOS 模擬器 / Android 模擬器，或安裝了開發版客戶端的真機 開發運行 # 克隆倉庫（包含 api submodule） git clone --recurse-submodules https://github.com/MoeKoeMusic/MoeKoeMusic-Mobile.git cd MoeKoeMusic-Mobile # 安裝依賴 npm install npm --prefix api install # 生成移動端 API 入口（api/ 更新後需重新執行） npm run generate:mobile-api # 啟動開發伺服器 npx expo start 如果克隆時遺漏了 submodule，可執行 git submodule update --init 补齊。 ...

規則： 保持 Markdown 結構。 不翻譯 URL 和代碼。 只返回翻譯內容，不附加其他評論。 MoeKoe 音樂擴展 MoeKoe 音樂瀏覽器擴展版，基於 MoeKoeMusic Web 构建並在瀏覽器擴展內完成 API 路由兼容。 🌎 GitHub 存儲庫 特性 點擊瀏覽器擴展圖標後打開獨立窗口運行 MoeKoeMusic。 不需要用戶配置 API 地址，也無需額外啟動本地 API 服務。 保留 MoeKoeMusic 原有 Web 頁面與互動，兼容瀏覽器擴展運行環境。 快速開始 環境要求 Node.js 20 或更高版本 Git Chrome / Edge 等 Chromium 内核瀏覽器 安裝依賴 git submodule update --init --recursive npm install npm run install:app npm run install:app 將分別安裝 MoeKoeMusic 和 MoeKoeMusic/api 的依賴。安裝後建議檢查子模塊工作區，避免把上游 lockfile 的非預期變化提交進去。 ...

在開發插件市場之前，先有的是 MoeKoe 的普通插件系統。 當時我想解決的問題不是某一個具體功能，而是一個更通用的问题：播放器裡總會冒出很多小需求，有些人想改界面，有些人想加一個工具彈窗，有些人想接自己的服務。如果每個想法都往主程序裡塞，主程序會越來越重，也越來越難維護。 所以我一開始給插件系統定的方向很明確：主程序只提供插件運行環境和管理入口，具體功能交給插件自己去做。插件能獨立安裝、獨立卸載，壞了也盡量不要影響播放器本身。 上一篇文章我寫的是 MoeKoeMusic-Plugins 這個插件登記倉庫。那邊解決的是“插件市場的數據怎麼產生”：用戶用 Issue 提交，Action 校驗，維護者審核，通過後寫進 plugins.json。 但只有登記倉庫還不夠。真正對用戶來說，插件市場不是 GitHub 上的一份 JSON，而是客戶端裡一個能看、能搜、能安裝、能更新的入口。 所以這篇就換到 MoeKoe Music 主項目裡，專門聊客戶端的插件市場部分。 為什麼選擇 Chrome Extension 這一套 MoeKoe 是 Electron 應用，Electron 本身就有加載擴展的能力。既然底层已經能跑 Chrome Extension，那就沒有必要再從零設計一套插件格式。 這樣做有幾個好處: 第一，插件作者不用學一套完全陌生的格式。manifest.json、popup.html、background.js 都是很常見的概念。 第二，插件天然有清單文件。主程序可以先讀 manifest.json，判斷插件名稱、版本、描述、權限、彈窗入口、最低支持版本等信息。 第三，Electron 可以直接加載插件目錄，不需要我自己寫一個腳本沙箱。 展示、搜索、分頁和狀態 插件市場不只是能安裝就行，還要能快速判斷： 這個插件是幹什麼的 我有没有安裝過 我安裝的是不是舊版本 這個插件有没有更高版本要求 它有没有網絡、文件訪問、本地二進制這些風險點 分頁、搜索、更新、狀態 所以市場卡片裡展示的不只是“安裝”按鈕。 確保插件目錄存在 調用 Electron 下載安裝、卸載舊版、安裝新版 註冊插件相關 IPC 加載 Chrome 擴展 加載 Native Host 索引和授權系統 已安裝插件 插件管理頁面的“已安裝插件”不只是讀取 Electron 當前加載的擴展。它會把兩類信息合併： session.defaultSession.getAllExtensions() 拿到已加載擴展 scanExtensions() 扫描磁盤插件目錄，讀取 manifest、圖標、彈窗、Native Host 声明 前端拿到這些字段後，就能顯示： ...

起初在構建 MoeKoe Music 插件生態時，還沒有線上插件市場這個功能 後來在社區的建議下便有了這個插件市場 增加官方/社區插件倉庫以擴展產品功能 插件可以由社區開發，那插件市場應該怎麼管？ 最直接的做法當然是把所有插件源碼都收進一個大倉庫裡。但這個方案越想越彆扭。每個插件都有自己的作者、自己的發佈節奏、自己的構建方式。把它們全塞進官方倉庫，不僅維護成本高，也會把責任邊界搞得很模糊。 所以這個倉庫最後沒有被設計成「插件源碼倉庫」，而是變成了一個「插件登記與索引倉庫」。它只做幾件事： 接收插件上架、更新、下架和舉報申請 自動做一輪基礎校驗和靜態識別 把人工審核通過時的插件快照記錄下來 維護客戶端可以讀取的 plugins.json 順手把 README 裡的插件列表更新出來，方便人看 一個可追溯的登記簿：誰提交的、審核的是哪個版本、下載地址是什麼、是否有網絡或文件權限，都落在一份清楚的數據裡。 市場索引，而不是源碼倉庫 倉庫根目錄最重要的文件是 plugins.json。它就是插件市場真正消費的數據源。 { "id": "custom-app-background", "name": "自定義背景圖", "description": "為MoeKoe Music提供自定義背景圖能力，支持透明度調節。", "iconUrl": "...", "version": "1.0.0", "minversion": "1.6.1", "...":"....", "buildRequired": false, "networkAccess": false, "fileAccess": false, "binaryContent": false, "snapshot": { "iconUrl": "...", "repository": "MoeKoeMusic/custom-app-background-plugin", "commitSha": "dbf72d38c8cf6b1d1cefdf8ce15798d565678995", "downloadUrl": "hxx.zip", "release": null } } 我不想讓市場記錄永遠指向插件倉庫「當前最新代碼」。因為作者今天提交的代碼，和審核那天看到的代碼，可能已經不是同一份東西了。插件市場真正應該承認的是：審核通過時的那個版本。 所以這個專案裡面有一個核心原則： 上架的不是一個會漂移的倉庫地址，而是一個已經鎖定的快照。 對於不需要編譯的插件，快照鎖到默認分支當時的 commit。對於需要編譯的插件，快照鎖到對應的 Release tag 和發行附件。這樣後面真出了問題，也能回頭知道當時到底審核了什麼。 Action 先跑，人最後拍板 用戶提交 Issue 時，需要選擇： ...

緊接上文：《同一個動畫，我用三種技術棧實現的區別?》 WebGL 二次元石頭剪刀布小遊戲。 規則很普通： 石頭 > 剪刀 剪刀 > 布 布 > 石頭 但有趣的是在於： 輸了會脫衣服。 對,就是這麼簡單粗暴。 起因其實是「我想研究精靈圖」 一開始我根本沒想做遊戲。 我只是想研究： atlas sprite 圖層疊加 動畫裁剪 這些東西。 然後想著：「總得有個實際應用場景吧？」 於是腦子一抽： 那乾脆做個二次元脫衣猜拳。 然後項目開始朝奇怪方向狂奔。 這個項目最麻煩的其實不是遊戲邏輯 石頭剪刀布規則簡單得離譜。 真正麻煩的是：衣服層級 因為角色不是：「一張完整圖片」 而是： 底圖 (防粿體被抓包,特意加密了) 衣服 A 衣服 B 衣服 C 配飾 遮擋層 不停疊。 「脫衣」其實是圖層管理 玩家贏了： 按設定好的順序移除一件衣服 電腦贏了： 再按逆序穿回來 聽起來簡單。 實際上會遇到一堆問題： 比如「不能瞬間露底圖」 這個特別關鍵。 如果你： 先刪舊衣服 再加新衣服 中間可能會閃出底圖。 於是視覺效果會特別怪。 所以我後來用了：reveal 覆蓋邏輯 新的層會立刻頂上。 盡量避免： 「裸體一幀閃現」。 雖然本身這項目看起來不正經 但至少技術上要優雅。 WebGL 在這裡真的很舒服 這個項目我最後選 WebGL 做。 原因很簡單：圖層太多。 ...

最近我做了個挺有意思的小實驗。 我把一個二次元角色的小動畫效果，分別用： WebGL Canvas 2D 純 DOM + CSS 實現了三遍。 效果本身不複雜： 眨眼 眉毛/下眼皮聯動 流汗輕微飄動 呆毛甩動 但真正有意思的，其實不是「做出來」。 而是： 同一個東西，用三種技術棧實現時，到底會差多少？ 本質上就是一次「前端圖形學味很濃」的復刻實驗。 一開始只是想復刻一個呆毛動畫 靈感來源：https://tamanidamani.itch.io/nijikas-ahoge 我當時想法特別簡單：「如果是我,要怎麼實現？」 然後越做越上頭。最後直接演變成： 那我乾脆把 WebGL、Canvas2D、DOM 三種方案都做一遍算了。 於是倉庫就變成了現在這樣： canvas/ canvas2D/ dom/ 三個版本同效果實現。 先說結論 如果只讓我說一句話： WebGL 最強，但 Canvas2D 最舒服，DOM 最適合業務 1. WebGL 版本：最像「真正遊戲開發」 這個版本是最折騰的。 因為它本質上已經不是「前端動畫」了, 而是：GPU 圖形編程 它到底怎麼實現的？ 核心思路其實就是： 底圖一層 精靈圖一層層貼 shader 控制繪製 JS 驅動動畫參數 比如： 呆毛旋轉 眨眼裁剪 alpha 混合 這些其實都在 GPU 那邊做。 你會開始接觸： uniform texture shader UV 頂點座標 紋理座標 然後人會逐漸失去笑容。 但 WebGL 真強 當元素一多的時候, WebGL 那種： 「完全不慌」 的感覺特別明顯。 尤其是： ...

最近寫程式碼的時候，我有一種很奇怪的感覺。 不是寫不動了，也不是不想寫，而是—— 好像越來越不需要我寫了。 以前一個功能，從需求到上線，基本是這樣的路徑： 我理解需求 → 設計方案 → 寫程式碼 → 除錯 → 改 bug → 上線 現在變成什麼樣？ 我描述需求 → AI 寫程式碼 → AI 改 bug → 我看一眼 → 上線 中間那一大段「寫程式碼」的過程，突然變得很薄，甚至可以沒有。 這件事，一開始挺爽的。 但爽著爽著，會有一點不安。 過去程式設計師，除了「完成任務」後獲得的成就感，在整個寫程式碼的過程中也能體會到很多樂趣。 寫程式碼這件事，好像沒那麼重要了 我以前一直覺得，程式設計師最核心的能力，就是寫程式碼。 你寫得快不快、優不優雅、抽象得好不好，這些東西構成了「水準」的差異。 但現在，這套標準在慢慢失效。 很多程式碼，其實 AI 寫得比人快，也不一定比人差。 尤其是那種： CRUD 介面串接 常規邏輯處理 這些東西，AI 基本上是碾壓式效率。 有時候我自己寫了一段，還會下意識丟給 AI： 「你幫我優化一下」 結果它不僅優化了，還順手把我沒想到的情況補上了。 那一刻會有一點微妙—— 你開始分不清，這段程式碼到底是誰寫的。 更詭異的是：你開始不想自己寫了 這才是最危險的。 以前寫程式碼，是一種「控制感」： 每一行都是我敲出來的，我知道它為什麼這樣寫，也知道哪裡可能出問題。 但現在，當你習慣把問題丟給 AI，你會發現： 自己寫，反而變慢了。 甚至會有一種感覺： 「我為什麼要親自寫？」 這不是偷懶，這是效率的自然選擇。 就像你不會手算大整數一樣，你也不會再想手動寫那些「可以被自動完成」的程式碼。 程式設計師，正在變成另外一種角色 慢慢你會發現，你每天在做的事情變了。 不再是： ...

這是一個100%去中心化的區塊鏈紅包應用。用戶可以連接錢包，設定金額和數量發送紅包，然後透過連結分享給他人領取。所有資料和操作都基於區塊鏈，完全不需要中心化伺服器，整個過程安全、透明、可追溯。 如果你感興趣，可以在 GitHub 上看看我的程式碼：redpacket‑dapp 功能亮點 🧧 發送紅包: 連接錢包後，設定金額和數量發送紅包到區塊鏈 🎁 領取紅包: 透過分享連結，別人可以連接錢包直接從區塊鏈領取紅包 🔗 智能合約: 使用 Solidity 編寫的安全智能合約處理所有邏輯 🌐 多鏈支援: 支援本地測試網和 BSC 測試網 💼 Web3 整合: 使用 MetaMask 錢包連接 🚀 完全去中心化: 沒有後端伺服器，所有資料儲存在區塊鏈 技術棧 前端：React 19、React Router 6、TypeScript、Vite、Ethers v6 合約層：Hardhat、Solidity 0.8.x 工具：ESLint、Prettier 不需要後端: 零依賴伺服器 ❌ 快速啟動 # 1. 安裝專案依賴 npm install cd react-dapp && npm install && cd .. # 2. 啟動本地區塊鏈節點 npm run node # 3. 編譯智能合約 npx hardhat compile # 4. 部署智能合約 npm run deploy # 5. 啟動前端 npm run frontend 目錄結構 redpacket-web3/ ├─ contracts/ # Solidity 智能合約 │ └─ RedPacket.sol ├─ react-dapp/ # React + Vite 前端 │ ├─ src/ │ │ ├─ components/ # 通用組件（錢包按鈕、創建表單等） │ │ ├─ config/ # ABI、合約地址配置 │ │ ├─ hooks/ # 自定義 hooks（useWallet） │ │ ├─ pages/ # 頁面（Home、ClaimPacket） │ │ ├─ styles/ # 全域樣式 │ │ ├─ utils/ # Web3 工具函數 │ │ └─ App.tsx # 路由與佈局 │ ├─ .env.example # 前端所需環境變數說明 │ └─ package.json ├─ scripts/ │ └─ deploy.js # Hardhat 部署腳本（會自動寫入前端配置） ├─ hardhat.config.js └─ package.json # 根目錄腳本（Hardhat + 前端一鍵啟動） 使用指南 創建紅包 打開前端並點擊右上角「連接錢包」。 填寫紅包總金額與份數，應用會在前端隨機拆分金額。 提交後在 MetaMask 中確認交易，等待區塊確認。 成功後可複製系統生成的領取連結，分享給朋友。 領取紅包 打開分享連結（URL 帶有 /claim/{packetId}）。 同樣先連接錢包，然後點擊「點擊領取」。 簽名確認後等待區塊打包，頁面會顯示結果與剩餘份數。 環境變數 dapp/.env（開發環境會自動忽略，請參考 .env.example） VITE_RPC_URL：前端直連節點 RPC，預設為 http://127.0.0.1:8545 VITE_CONTRACT_ADDRESS：可覆蓋部署腳本寫入的地址 VITE_CHAIN_ID：前端提示使用的鏈 ID（十六進制） root/.env：若需要在 Hardhat 中引用私鑰或 BSC RPC，可繼續沿用原有寫法。 智能合約（RedPacket.sol） 核心方法： ...

✨ 緒山真尋的小窩 ✨ 🌸 歡迎來到緒山真尋的小窩 🌸 哇！你發現了我的秘密基地！(*≧ω≦) 這裡是緒山真尋的個人網站，充滿了可愛的動畫和有趣的內容！我會在這裡分享我喜歡的動畫、漫畫、遊戲和一些日常生活中的小確幸～ 💕 關於我 💕 我是緒山真尋，一個熱愛成人遊戲的家裡蹲廢柴尼特族。喜歡動畫、漫畫、輕小說和各種可愛的東西！最喜歡的顏色是粉色和淡藍色！ ∩∩ （･ω･） <- 這是我！ ＿|　⊃／(＿＿ ／ └-(＿＿＿／ 🎀 網站內容 🎀 🌟 精美動畫展示 📚 我的私房照 🎵 好聽的音樂 📷 日常生活的小片段 🌈 關於 🌈 🎭 演示: https://mahiro.moejue.cn/ 🏠 個人部落格: https://MoeJue.cn/ 🐱 GitHub: https://github.com/iAJue/Mahiro 📧 官方網站: https://onimai.jp/ 📝 版權聲明 📝 本網站由 @Moejue 設計和開發 網站中使用的所有動畫片段、漫畫圖片、角色形象及相關內容的版權均歸原作者(ねことうふ（Nekotofu）)及其發行公司(Studio Bind、Ichijinsha)所有 如有侵權，請透過以上聯絡方式告知，我會立即刪除相關內容 GNU GENERAL PUBLIC LICENSE Version 2 Copyright © 2025 MoeJue. All rights reserved. 💌 特別感謝 💌 感謝所有喜歡緒山真尋的朋友們！(●’◡’●) ...