代码

起初在構建 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，你會發現： 自己寫，反而變慢了。 甚至會有一種感覺： 「我為什麼要親自寫？」 這不是偷懶，這是效率的自然選擇。 就像你不會手算大整數一樣，你也不會再想手動寫那些「可以被自動完成」的程式碼。 程式設計師，正在變成另外一種角色 慢慢你會發現，你每天在做的事情變了。 不再是： ...

最近，我給個人部落格來了次「大動作」—— 從單語言版本升級到了 多語言站點（簡體中文、繁體中文、英語、日語）， 並且全流程實現了自動化。💪 主要包括： 自動同步主站文章 自動 AI 翻譯內容 自動建構與部署多語言站點 為何選擇 Hugo？ 因為它那句自信的口號： 「The world’s fastest framework for building websites.」 —— 就這句話，我就決定是它了 😆。 不過我沒有採用「一套主題多語言切換」的傳統做法， 而是讓 每種語言都有獨立主題。 這樣每個語言版本都能保留自己的美學與排版風格， 真正做到「文化層面的在地化」。 設計目標與約束 🎯 語言：支援簡中、繁中、英文、日文，未來還可擴展。 主題：每種語言使用最合適的 Hugo 主題，而非強行複用。 內容同步：所有語言共用一份內容儲存庫，按需翻譯。 部署策略：各語言獨立建構與發布，可部署到不同分支或網域。 客製化頁面：像「友鏈」、「書房」、「歸檔」等頁面要在多語言下保持一致體驗。 多語言配置策略 🧩 我為每個語言單獨準備了一個設定檔： config/<lang>.toml，它們主要負責： 指定主題（例如 theme = "PaperMod"）。 定義該語言特有的 title / description / keywords。 重寫選單設定 [[params.menu]]，以匹配不同主題的導航結構。 注入客製化樣式，確保整體視覺一致。 這種結構非常清晰，也方便未來擴展更多語言版本。 GitHub Actions 自動部署矩陣 ⚙️ CI/CD 部分完全交給 GitHub Actions 來處理。 在 .github/workflows/hugo.yml 中，我使用了 矩陣建構， 為每種語言獨立建構、發布： matrix: include: - lang: en config: config/en.toml publish_branch: dist-en - lang: zh-cn config: config/zh.toml publish_branch: dist-zh - lang: ja config: config/ja.toml publish_branch: dist-ja - lang: zh-hant config: config/zh-hant.toml publish_branch: dist-zh-hant 建構階段 👇 ...

還記得那個被你們玩壞的隨機圖接口嗎？今天它更新了！ 在過去的幾年裡，隨機圖 API 一直是許多前端開發者、二次元站長、甚至桌面插件愛好者的「小玩具」與「常用工具」。 🥇 第一代：簡單但笨重的起點 那時候的隨機圖 API，說實話—— 就是一個 PHP 小腳本 + 一台雲主機。 那時的目標很簡單：提供一個能返回隨機圖片的接口。 特點如下： 所有請求都集中在一台伺服器上； 圖片儲存與 API 服務耦合在一起； 無快取，無智能分發，完全依賴單點性能； 高峰期 CPU 飆升、502 報錯、訪問慢、費流量佔儲存； [客戶端] ---> [中心伺服器(唯一)] ---> [圖片文件] 🥈 第二代：雲化與快取的過渡時代 進入第二代後，隨機圖 API 邁入了「雲化」階段。 服務遷上雲、引入快取、CDN、負載分發都安排上。 主要變化： 圖片統一託管在第三方圖床（如新浪圖床）； 接口運行在雲主機或輕量應用伺服器上； 增加了基礎快取邏輯（例如 Redis 或 Nginx 快取層）； 服務整體更穩定，訪問速度也顯著提升。 [客戶端] ↓ [雲伺服器接口層] --> [CDN 快取] --> [圖床(Sina)] 訪問仍需經過中心伺服器中轉，遇到高併發或地區網路分佈不均時，延遲依舊明顯。 所有請求還是得經過「中心伺服器」， 一旦伺服器抽風，全體陪葬 💀。 🚀 第三代隨機圖 API 來了！ ✨ 核心亮點 第三代隨機圖 API 是一次 架構級重生。 依托於 騰訊雲 EdgeOne 超過 3200+ 邊緣節點 的強大能力， 請求可在 全球範圍內自動調度 到離用戶最近的節點執行，實現了真正的 去中心化分佈式架構。 ...

✨ 緒山真尋的小窩 ✨ 🌸 歡迎來到緒山真尋的小窩 🌸 哇！你發現了我的秘密基地！(*≧ω≦) 這裡是緒山真尋的個人網站，充滿了可愛的動畫和有趣的內容！我會在這裡分享我喜歡的動畫、漫畫、遊戲和一些日常生活中的小確幸～ 💕 關於我 💕 我是緒山真尋，一個熱愛成人遊戲的家裡蹲廢柴尼特族。喜歡動畫、漫畫、輕小說和各種可愛的東西！最喜歡的顏色是粉色和淡藍色！ ∩∩ （･ω･） <- 這是我！ ＿|　⊃／(＿＿ ／ └-(＿＿＿／ 🎀 網站內容 🎀 🌟 精美動畫展示 📚 我的私房照 🎵 好聽的音樂 📷 日常生活的小片段 🌈 關於 🌈 🎭 演示: 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. 💌 特別感謝 💌 感謝所有喜歡緒山真尋的朋友們！(●’◡’●) ...

多鏈錢包整合的實踐反思 總算是空閒下來可以整理一下程式碼了，Web3 專案接入多鏈錢包連接功能，主要涉及 Ethereum、Polygon、BSC 和 Solana。乍一聽好像只是「多做幾套相容邏輯」的事，但真正落地後才發現，很多東西其實沒想得那麼簡單。 this.networkConfigs = { ethereum: { chainId: '0x1', // 1 chainName: 'Ethereum Mainnet', nativeCurrency: { name: 'Ethereum', symbol: 'ETH', decimals: 18 }, rpcUrls: ['https://eth-mainnet.public.blastapi.io'], blockExplorerUrls: ['https://etherscan.io'] }, polygon: { chainId: '0x89', // 137 chainName: 'Polygon Mainnet', nativeCurrency: { name: 'MATIC', symbol: 'MATIC', decimals: 18 }, rpcUrls: ['https://polygon-rpc.com'], blockExplorerUrls: ['https://polygonscan.com'] }, bsc: { chainId: '0x38', // 56 chainName: 'BNB Smart Chain', nativeCurrency: { name: 'BNB', symbol: 'BNB', decimals: 18 }, rpcUrls: ['https://bsc-dataseed.binance.org'], blockExplorerUrls: ['https://bscscan.com'] } } 多鏈並非簡單的「支援多個錢包」 最大的感受是：鏈不一樣，錢包互動方式也不一樣，連 SDK 的思維方式都不一樣。以太坊生態可以用統一的 Web3.js 處理很多邏輯，而到了 Solana，你會發現它完全是另一套系統：Provider 接入、連接流程、PublicKey 建構方式都不太一樣，甚至連網路延遲和穩定性都影響體驗。 ...

專案概述 在當今的 Web 開發領域，使用者體驗和介面設計變得越來越重要。 Mac Web Vue Template 是一個受 macOS 設計啟發的現代優雅的 Vue.js Web 模板，它是一個基於 Vue.js 的現代化 Web 應用模板，其設計靈感來源於 macOS 的優雅介面。這個專案不僅提供了美觀的 UI 設計，還包含了完整的專案結構和最佳實踐。 線上演示 你可以透過造訪 WebAi 來體驗這個模板的實際效果。邀請碼(MoeJue) 核心特色 macOS 風格的 UI 設計 採用 macOS 的設計語言 精緻的毛玻璃效果 優雅的動畫過渡 現代化的技術棧 Vue.js 作為核心框架 Vite 作為建構工具 Pinia 進行狀態管理 Vue Router 處理路由 SCSS 預處理器 ES6+ 現代特性 響應式設計 完美適配各種螢幕尺寸 流暢的行動裝置體驗 專案結構解析 專案採用了清晰且模組化的目錄結構： src/ ├── assets/ # 靜態資源 ├── components/ # Vue 組件 │ ├── common/ # 通用組件 │ ├── system/ # 系統組件 │ └── apps/ # 應用組件 ├── views/ # 頁面視圖 ├── router/ # 路由配置 ├── stores/ # 狀態管理 └── utils/ # 工具函數 這種結構設計使得專案具有良好的可維護性和可擴展性。 ...

ArticleSync - 多平台文章同步插件 ArticleSync 是一個瀏覽器擴充功能，幫助使用者輕鬆將文章同步發佈到多個社交平台。支援將文章從本地草稿發佈到各大平台，如知乎、Bilibili 等。它提供了一站式解決方案，讓你在不同的社交媒體平台上同步文章變得簡單高效。 基於瀏覽器外掛程式模式，自動偵測本地登入帳號，杜絕帳號洩露、環境異常等風險 基於 Chrome Manifest v3 瀏覽器擴充功能標準開發，請注意核心版本要求 背景 你也知道，我這又一下子多了好幾個部落格平台，和一大堆社交網站，如果我想讓它們之間都能保持活躍的更新怎麼辦。(證明我還活著) 還能一鍵盜文章 我最常更新的就是我自己的小破站了，但是其他平台，我可能就只是偶爾更新一下，但是又不想每次都去手動發佈，所以我就想，能不能寫一個外掛程式，自動偵測我本地登入的帳號，然後自動發佈呢。 正所謂，自己動手豐衣足食。鼓搗了好幾天，勉強算是能用的樣子，剩下的就有空再更新了。除非你給我錢 外掛程式還有很多不完善的地方，我也沒有多平台正式在生產環境中實測，如遇報錯，實屬正常，那就提交 issue 吧，或者自己改改，改好了再提交 PR 吧。嘻嘻~ 為了不影響我說話，截圖放最後了 還有，開源不易，來個 star 吧，嘿嘿嘿~ 本來想加一點私貨進去的，自動關注我的社群平台 功能特色 多平台支援：支援知乎、Bilibili 等各大主流平台，支援自建開源 CMS 系統。 狀態追蹤：在外掛程式介面中查看文章的同步狀態。 帳號管理：可查看與外掛程式綁定的各平台帳號資訊。 可擴展性強：支援開發者透過轉接器模式輕鬆擴展到更多平台。 安全可靠：外掛程式基於瀏覽器擴充功能模式，確保帳號安全，避免帳號洩露等風險。 待辦事項 [ ] 獨立文章編輯器 [ ] 圖片一鍵同步 [x] Markdown 與 HTML 互轉 [ ] 第三方圖床系統 [ ] 多帳號管理 [ ] 多系統客戶端版本 [ ] 一鍵 AI 總結 [ ] 影片同步 [ ] 標籤、分類的支援 [ ] 更友善的錯誤處理 [ ] 更多平台的接入 支援管道 媒體 ...