编程 on 阿珏酱のBlog

【进行中】阿珏Blog十周年特别纪念活动

xxx@example.com (MoeJue) — Sat, 19 Sep 2026 00:01:17 +0000

【进行中】阿珏Blog十周年特别纪念活动

作者：MoeJue（xxx@example.com）

不知不觉，十年了。

那年的今日,我买了一个域名,租了个虚拟主机,部署了一套博客系统,发表了第一篇文章.

就从那时开始,开始折腾起了这个博客，我大概也没想过，一个博客居然真的能活了十年。

这十年里面换过域名、换过服务器、换过主题，也写过一些现在回头看自己都觉得“这是什么东西”的文章。

当然也断更过。

但不管怎么说，

它真的活到了十周年。

按惯例【已结束】阿珏Blog三周年特别纪念活动,必然不能这写这一篇文章. ps:这个活动我已经提前好几年就已经开始策划了.

更多的十周年总结部分我准备放到今年的年终总结去,这次就专注哈皮!

🎉 十周年特别纪念活动

这次活动依旧分成两部分：

① 🧩 解密游戏

不要只看页面上显示出来的东西。
链接、图片、文字、源码……
说不定都有用。

② ✍️十周年文章活动

在自己博客发表一篇任意标题的文章，说出对阿珏的祝福、对阿珏Blog的评价、对阿珏想要说的话，和阿珏经历过的故事等等内容，如果感动到阿珏了呢，那恭喜你哟，中奖啦！
一个人写一篇是一种记录，一群人写下来，就是一段共同的互联网记忆了。

📅 活动时间

2026 年 9 月 19 日 – 2026 年 10 月 19 日

在活动时间内，都可以参加解密游戏和文章活动。

兑奖方式

使用兑换码在萌音商城自主下单兑奖
当你中奖时，届时阿珏将通过 moejue@qq.com 发送兑换码到你的评论时所使用的邮箱地址
可选内容，性别、年龄、有无男/女朋友、自拍照、手机型号等，有利于福袋许愿
所有交易方式均为私密方式，不会向任何第三方透露
随机快递包邮，不接受指定
兑换码将在活动结束后正式生效
同一碳基个体仅限一份福袋
奖品会在兑奖后十个自然日内安排寄出

活动规则

仅限熟人
仅限拥有个人博客的博主
仅限看到这篇文章的人
仅限人品很好的人
仅限很帅的人
仅限很可爱的人
我就是规则！

🎁 福袋预览

手办、公仔、挂件、笔、耳机、卡贴、徽章、明信片、笔记本、扇子、项链、手机贴膜、手绳、戒子、垫子、小抱枕、玩偶、变身棒、ZWB、H漫画、女友、月饼、垃圾、卡片、阿珏酱等内容。

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

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

Web3 链上红包 DApp

xxx@example.com (MoeJue) — Sat, 10 Jan 2026 14:02:35 +0000

Web3 链上红包 DApp

作者：MoeJue（xxx@example.com）

这是一个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）

核心方法：

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

萌音商城移动端版本发售

xxx@example.com (MoeJue) — Thu, 17 Apr 2025 09:07:11 +0000

萌音商城移动端版本发售

作者：MoeJue（xxx@example.com）

项目介绍

萌音商城移动版是一个基于uniapp开发的多端商城系统，支持iOS、Android、H5及小程序等多个平台。系统采用PHP + MySQL + FastAdmin作为后端技术栈，实现了完整的电商功能。

核心功能

商品管理：分类、列表、详情展示
购物流程：购物车、结算、支付、订单管理
用户系统：会员中心、个人信息管理
多商户模式：商户独立管理商品与订单
发货系统: 支持推送订单至ERP(管家婆)系统处理
双模式交易：
- 线上下单快递发货
- 线上下单到店自取/骑手配送

系统预览

后台管理界面

小程序端界面

版本说明

当前版本为V1.0版，部分界面为预留规划，将根据实际需求持续更新完善。由于没有正式发布版本，上线小程序运营，所以没有线上版本可供演示目前程序处于V1.0初版，部分界面是提前预留规划的，后期会根据需求进行更新

购买说明

价格：188元 (版本更新后将会视情况调整价格，请以实际价格为准)
内容：完整源代码（含移动端和后台，无加密无授权）
推荐返利：推荐好友购买可获20%返利
更新服务：终身免费更新
使用须知：禁止私自转售，违规将停止更新服务
开发支持：源码含详细注释，方便二次开发
项目托管：代码托管于GitHub，更新日志完整透明
多端支持: 需要自行编译其他客户端，基于微信小程序环境开

联系方式

QQ交流群：点击加入
由于没有个人QQ链接，加群后请@群主咨询购买事宜
项目滞销了，请帮帮阿珏酱

在线演示

微信小程序端演示视频
后台演示环境请联系咨询
微信小程序可联系添加体验权限

本文2025-04-17首发于阿珏酱のBlog，最后修改于2025-09-06