Posts

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

8 月 8 日，又去漫展了。 這次是第十屆迷鹿動漫展。 最近感覺自己參加漫展已經越來越熟練了，基本就是看到漫展，有時間的話就去。 也沒什麼特別的目的。 就是想去逛逛，然後順便拍拍Cos，看看有沒有認識的人。 说白了就是： 趁年輕做點自己喜歡的事情 照片 回家以後當然還是要面對熟悉的環節。 導照片。 然後打開一看： “怎麼這麼多？” 開始慢慢篩。 這張留。 那張留。 有些照片自己覺得還不錯，就留了下來。 有些雖然拍得一般，但又覺得刪掉有點可惜。 最後就變成： “算了，都留着吧。” 修完以後再慢慢發社交平台。 然後過一段時間再回來看。 估計又會覺得： “當時怎麼不再拍好一點。” 很正常。 下次繼續。 這次就先記錄到這裡 第十屆迷鹿動漫展。 又是一次很普通的漫展。 沒有什麼特別的故事。 “哦，2026 年 8 月 8 日，我去過迷鹿。” 這就夠了。 下次有漫展的話…… 那就繼續去。 📷 阿珏醬 / 漫展隨手記錄 第十屆迷鹿動漫展，完。

規則： 保持 Markdown 結構。 不翻譯 URL 和代碼。 只返回翻譯內容，不附加評論。 這次旅行，去的是傳說中的“中國最美十大海島”之一，嵛山島。 出發之前還是挺期待的。 畢竟這種地方，網上隨便一搜都是各種大片：藍藍的海水、層層疊疊的山、遠處的海島，還有站在山頂一眼望過去的壯闊海景。 結果真正到了以後才發現—— 旅行這種東西，真的很看天氣。 登島 剛開始的時候，天氣其實還可以。 一路上看看風景，吹吹海風，感覺整個人都慢慢放鬆下來了。 島上的風景和城市裡完全不一樣。 沒有那麼多高樓，也沒有那麼嘈雜的聲音，視線一下子就開闊了很多。 一路走走停停，看到喜歡的地方就拍拍照片。 上山 在山腳下，天氣看起來其實還行。 但是隨著海拔越來越高，周圍慢慢就開始白了起來。 遠處的山看不見了。 海也看不見了。 甚至走到一些地方時，前面十幾二十米的东西都開始變得模糊。 一開始還只是有一點霧氣，後來直接變成了“霧鎖山頂”。 到了山頂之後，遠處基本就看不到了，而且那天風還特別的大，呼呼的吹 本來應該能看到很遠的海面，結果全被白茫茫的霧氣擋住。 站在那裡甚至有一種：“我是不是來到了雲裡面？” 的感覺。 當然，沒看到完整的山海全貌，還是有一點遺憾的。 畢竟難得來一次嵛山島，還是很想親眼看看網上照片裡的那種壯闊海景。 網上那些“站在山頂俯瞰大海”的畫面，我是一張都沒看到。 這裡就是最有名的大天湖和小天湖哈哈 最出片的地方 去海邊 到了海邊之後，感覺又完全不一樣了。 海風吹過來，整個人舒服了很多。 相比于山頂的時候，海邊更加適合慢慢待著。 沒有必須一直趕著去什麼景點，也沒有必須一直拿著相機拍。 代畫小人,一元一個,童叟無欺 看日落 到了傍晚，我們又準備等日落。 這時候其實已經開始期待了。 想著白天山頂雖然沒看到完整的海景，那晚上總得讓我看個日落吧？ 結果…… 雲又來了。 太陽慢慢往下落時，天空已經被雲層擋住了。 能看到一點點夕陽的光，但是想像中的那種“太陽落到海平面”的畫面，還是沒有等到。 树蔭下 島上有一個砲台酒吧，晚上時候會有許多年輕人在這唱歌喝酒。 吹吹海風，聊聊天，看看旁邊的海。 那一刻其實特別輕鬆惬意。 旅行有時候就是這樣。 不一定非要去很多地方，也不一定每一分鐘都安排得滿滿當當。 有時候找個樹蔭坐下來，吹一會兒海風，就已經很放鬆了。 ...

規則： 保持 Markdown 結構。 不翻譯 URL 和代碼。 只返回翻譯內容，不附加其他評論。 算起來，我去漫展也有一段時間了。 不過如果要問我到底算什麼身份…… 攝影師？算是吧。 集郵黨？也算。 二次元愛好者？這個應該更準確一點。 相機掛著，手機揣著，然後看到好看的 Cos 就走不動路。 這次去的是 福州·第十五屆潮柚次元動漫嘉年華。 展會在 2026 年 7 月 24 日到 26 日舉行，地點還是大家比較熟悉的福州海峽國際展覽中心。 出發，目標：拍照 + 集郵 一邊拍，一邊逛，一邊集郵。 你永遠不知道下一秒會在館內哪個角落遇到誰。 我的漫展日常 “老師，可以拍幾張嗎？” “老師，可以集個郵嗎！” “謝謝老師！” “老師，你看一下” “老師，需要反圖嗎, 加個微信吧” 這句話我感覺已經快變成攝影師的固定台詞了。 但我實際上不只是來拍照的 雖然每次都背著相機，看起來像個攝影師。 但我觉得自己還更像一個普通的漫展愛好者。 因為我也喜歡集郵。 遇到認識的老師，拍張照； 遇到喜歡的 Cos，拍張照； 遇到以前見過的老師，再拍張照。 有時候甚至不是為了出片。 就是覺得： “啊，這次又遇到他了。” 那就拍一張留個紀念。 我觉得這也是漫展比較有意思的一點。 幾年以後再翻回這些照片，你可能已經記不起當天具體發生了什麼。 但是看到照片的時候，還是會想起： “哦，這個漫展我去過。” “那天我好像還在這裡拍了一整天。” “當時這個老師還在這裡。” 這種感覺實在是挺好的。 漫展裡的各種瞬間 漫展最讓我喜歡的，實際上不一定是舞台或者嘉賓。 有時候就是一些很普通的瞬間。 路邊正在整理假發的 Coser。 ...

規則： 保持 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 那種： 「完全不慌」 的感覺特別明顯。 尤其是： ...