代码 on 阿珏酱のBlog

MoeKoe Music Mobile酷狗音乐第三方移动端播放器

xxx@example.com (MoeJue) — Sat, 01 Aug 2026 13:12:42 +0000

MoeKoe Music Mobile酷狗音乐第三方移动端播放器

作者：MoeJue（xxx@example.com）

# 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 补齐。

本文2026-08-01首发于阿珏酱のBlog，最后修改于2026-08-01

MoeKoe Music浏览器插件版本,开箱即用

xxx@example.com (MoeJue) — Wed, 15 Jul 2026 17:48:40 +0000

MoeKoe Music浏览器插件版本,开箱即用

作者：MoeJue（xxx@example.com）

MoeKoe Music Extension

MoeKoe Music 浏览器插件版，基于 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 的非预期变化提交进去。

本文2026-07-15首发于阿珏酱のBlog，最后修改于2026-07-15

MoeKoe Music 插件市场设计

xxx@example.com (MoeJue) — Sun, 05 Jul 2026 12:54:29 +0000

MoeKoe Music 插件市场设计

作者：MoeJue（xxx@example.com）

在做插件市场之前，先有的是 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、图标、popup、Native Host 声明

前端拿到这些字段后，就能显示：

本文2026-07-05首发于阿珏酱のBlog，最后修改于2026-07-05

MoeKoeMusic-Plugins设计理念

xxx@example.com (MoeJue) — Sat, 20 Jun 2026 11:45:33 +0000

MoeKoeMusic-Plugins设计理念

作者：MoeJue（xxx@example.com）

一开始做 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 时，需要选择：

本文2026-06-20首发于阿珏酱のBlog，最后修改于2026-06-20

我用WebGL做18+游戏，输了“掉装备”🔞

xxx@example.com (MoeJue) — Sat, 13 Jun 2026 11:38:47 +0000

我用WebGL做18+游戏，输了“掉装备”🔞

作者：MoeJue（xxx@example.com）

紧接上文：《同一个动画，我用三种技术栈实现的区别?》

WebGL 二次元石头剪刀布小游戏。

规则很普通：

石头 > 剪刀
剪刀 > 布
布 > 石头

但有趣的是在于：

输了会脱衣服。

对,就是这么简单粗暴。

起因其实是“我想研究精灵图”

一开始我根本没想做游戏。
我只是想研究：

atlas
sprite
图层叠加
动画裁剪

这些东西。
然后想着：“总得有个实际应用场景吧？”

于是脑子一抽：

那干脆做个二次元脱衣猜拳。

然后项目开始朝奇怪方向狂奔。

这个项目最麻烦的其实不是游戏逻辑

石头剪刀布规则简单得离谱。
真正麻烦的是：衣服层级
因为角色不是：“一张完整图片”

而是：

底图 (防粿体被抓包,特意加密了)
衣服 A
衣服 B
衣服 C
配饰
遮挡层

不停叠。

“脱衣”其实是图层管理

玩家赢了：

按设定好的顺序移除一件衣服

电脑赢了：

再按逆序穿回来

听起来简单。
实际上会遇到一堆问题：

比如“不能瞬间露底图”

这个特别关键。
如果你：

先删旧衣服
再加新衣服

中间可能会闪出底图。
于是视觉效果会特别怪。
所以我后来用了：reveal 覆盖逻辑

新的层会立刻顶上。
尽量避免：

本文2026-06-13首发于阿珏酱のBlog，最后修改于2026-06-13

同一个动画，我用三种技术栈实现的区别?

xxx@example.com (MoeJue) — Fri, 29 May 2026 20:54:39 +0000

同一个动画，我用三种技术栈实现的区别?

作者：MoeJue（xxx@example.com）

最近我做了个挺有意思的小实验。
我把一个二次元角色的小动画效果，分别用：

WebGL
Canvas 2D
纯 DOM + CSS

实现了三遍。
效果本身不复杂：

眨眼
眉毛/下眼皮联动
流汗轻微飘动
呆毛甩动

但真正有意思的，其实不是“做出来”。
而是：

同一个东西，用三种技术栈实现时，到底会差多少？

本质上就是一次“前端图形学味很浓”的复刻实验。

一开始只是想复刻一个呆毛动画

灵感来源：https://tamanidamani.itch.io/nijikas-ahoge
我当时想法特别简单：“如果是我,要怎么实现？”
然后越做越上头。最后直接演变成：

那我干脆把 WebGL、Canvas2D、DOM 三种方案都做一遍算了。

于是仓库就变成了现在这样：

三个版本同效果实现。

先说结论

如果只让我说一句话：

WebGL 最强，但 Canvas2D 最舒服，DOM 最适合业务

1. WebGL 版本：最像“真正游戏开发”

这个版本是最折腾的。
因为它本质上已经不是“前端动画”了, 而是：GPU 图形编程

它到底怎么实现的？

核心思路其实就是：

底图一层
精灵图一层层贴
shader 控制绘制
JS 驱动动画参数

比如：

呆毛旋转
眨眼裁剪
alpha 混合

这些其实都在 GPU 那边做。
你会开始接触：

uniform
texture
shader
UV
顶点坐标
纹理坐标

然后人会逐渐失去笑容。

本文2026-05-29首发于阿珏酱のBlog，最后修改于2026-05-29

杀死那个手写代码的人

xxx@example.com (MoeJue) — Tue, 05 May 2026 20:22:07 +0000

杀死那个手写代码的人

作者：MoeJue（xxx@example.com）

最近写代码的时候，我有一种很奇怪的感觉。

不是写不动了，也不是不想写，而是——
好像越来越不需要我写了。

以前一个功能，从需求到上线，基本是这样的路径：

我理解需求 → 设计方案 → 写代码 → 调试 → 改 bug → 上线

现在变成什么样？

我描述需求 → AI 写代码 → AI 改 bug → 我看一眼 → 上线

中间那一大段“写代码”的过程，突然变得很薄，甚至可以没有。

这件事，一开始挺爽的。
但爽着爽着，会有点不安。

过去程序员，除了「完成任务」后获得的成就感，在整个写代码的过程中也能体会到很多乐趣。

写代码这件事，好像没那么重要了

我以前一直觉得，程序员最核心的能力，就是写代码。

你写得快不快、优不优雅、抽象得好不好，这些东西构成了“水平”的差异。

但现在，这套标准在慢慢失效。

很多代码，其实 AI 写得比人快，也不一定比人差。

尤其是那种：

CRUD
接口对接
常规逻辑处理

这些东西，AI 基本是碾压式效率。

有时候我自己写了一段，还会下意识丢给 AI：

“你帮我优化一下”

结果它不仅优化了，还顺手把我没想到的情况补上了。

那一刻会有点微妙——
你开始分不清，这段代码到底是谁写的。

更诡异的是：你开始不想自己写了

这才是最危险的。

以前写代码，是一种“控制感”：

每一行都是我敲出来的，我知道它为什么这样写，也知道哪里可能出问题。

但现在，当你习惯了把问题丢给 AI，你会发现：

自己写，反而变慢了。

甚至会有一种感觉：

“我为什么要亲自写？”

这不是偷懒，这是效率的自然选择。

就像你不会手算大整数一样，你也不会再想手写那些“可以被自动完成”的代码。

程序员，正在变成另外一种角色

慢慢你会发现，你每天在做的事情变了。

本文2026-05-05首发于阿珏酱のBlog，最后修改于2026-05-05

阿珏のBlog 的国际化之路

xxx@example.com (MoeJue) — Sun, 02 Nov 2025 10:12:27 +0000

阿珏のBlog 的国际化之路

作者：MoeJue（xxx@example.com）

最近，我给个人博客来了次“大动作”——
从单语言版本升级到了 多语言站点（简体中文、繁体中文、英语、日语），
并且全流程实现了自动化。💪

主要包括：

自动同步主站文章
自动 AI 翻译内容
自动构建与部署多语言站点

为什么选择 Hugo？

因为它那句自信的口号：

“The world’s fastest framework for building websites.”

—— 就这句话，我就决定是它了 😆。

不过我没有采用“一套主题多语言切换”的传统做法，
而是让 每种语言都有独立主题。
这样每个语言版本都能保留自己的美学与排版风格，
真正做到“文化层面的本地化”。

设计目标与约束 🎯

语言：支持简中、繁中、英文、日文，未来还可扩展。
主题：每种语言使用最合适的 Hugo 主题，而非强行复用。
内容同步：所有语言共用一份内容仓库，按需翻译。
部署策略：各语言独立构建与发布，可部署到不同分支或域名。
定制页面：像“友链”、“书房”、“归档”等页面要在多语言下保持一致体验。

多语言配置策略 🧩

我为每个语言单独准备了一个配置文件：
config/.toml，它们主要负责：

指定主题（例如 theme = "PaperMod"）。
定义该语言特有的 title / description / keywords。
重写菜单配置 [[params.menu]]，以匹配不同主题的导航结构。
注入自定义样式，保证整体视觉一致。

这种结构非常清晰，也方便未来扩展更多语言版本。

GitHub Actions 自动部署矩阵 ⚙️

CI/CD 部分完全交给 GitHub Actions 来处理。
在 .github/workflows/hugo.yml 中，我使用了 矩阵构建，
为每种语言独立构建、发布：

本文2025-11-02首发于阿珏酱のBlog，最后修改于2025-11-02

第三代随机二次元 API 来了！

xxx@example.com (MoeJue) — Wed, 15 Oct 2025 01:31:22 +0000

第三代随机二次元 API 来了！

作者：MoeJue（xxx@example.com）

还记得那个被你们玩坏的随机图接口吗？今天它更新了！在过去的几年里，随机图 API 一直是许多前端开发者、二次元站长、甚至桌面插件爱好者的“小玩具”与“常用工具”。

🥇 第一代：简单但笨重的起点

那时候的随机图 API，说实话—— 就是一个 PHP 小脚本 + 一台云主机。那时的目标很简单：提供一个能返回随机图片的接口。

特点如下：

所有请求都集中在一台服务器上；
图片存储与 API 服务耦合在一起；
无缓存，无智能分发，完全依赖单点性能；
高峰期 CPU 飙升、502 报错、访问慢、费流量占储存；

[客户端] ---> [中心服务器(唯一)] ---> [图片文件]

🥈 第二代：云化与缓存的过渡时代

进入第二代后，随机图 API 迈入了“云化”阶段。服务迁上云、引入缓存、CDN、负载分发都安排上。

主要变化：

图片统一托管在第三方图床（如新浪图床）；
接口运行在云主机或轻量应用服务器上；
增加了基础缓存逻辑（例如 Redis 或 Nginx 缓存层）；
服务整体更稳定，访问速度也显著提升。

[客户端]
   ↓
[云服务器接口层] --> [CDN 缓存] --> [图床(Sina)]

访问仍需经过中心服务器中转，遇到高并发或地区网络分布不均时，延迟依旧明显。
所有请求还是得经过“中心服务器”，
一旦服务器抽风，全体陪葬 💀。

🚀 第三代随机图 API 来了！

✨ 核心亮点

第三代随机图 API 是一次 架构级重生。

依托于 腾讯云 EdgeOne 超过 3200+ 边缘节点 的强大能力，请求可在 全球范围内自动调度 到离用户最近的节点执行，实现了真正的 去中心化分布式架构。

本文2025-10-15首发于阿珏酱のBlog，最后修改于2025-10-15

我不会AE,但是我会Code

xxx@example.com (MoeJue) — Sat, 23 Aug 2025 12:29:01 +0000

我不会AE,但是我会Code

作者：MoeJue（xxx@example.com）

✨ 緒山まひろの小窝 ✨

🌸 欢迎来到緒山まひろの小窝 🌸

哇！你发现了我的秘密基地！(*≧ω≦)

这里是緒山まひろ的个人网站，充满了可爱的动画和有趣的内容！我会在这里分享我喜欢的动画、漫画、游戏和一些日常生活中的小确幸~

💕 关于我 💕

我是緒山まひろ，エロゲを愛する引きこもりのダメニート。喜欢动画、漫画、轻小说和各种可爱的东西！最喜欢的颜色是粉色和淡蓝色！

  ∩∩
（･ω･）  <- 这是我！
＿|　⊃／(＿＿
／ └-(＿＿＿／

🎀 网站内容 🎀

🌟 精美动画展示
📚 我的私房照
🎵 好听的音乐
📷 日常生活的小片段

🌈 关于 🌈

🎭 演示: 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

💌 特别感谢 💌

感谢所有喜欢緒山まひろ的朋友们！(●’◡’●)

本文2025-08-23首发于阿珏酱のBlog，最后修改于2025-08-23