一套面向 Bukkit 服务端的变量与积分管理框架。 起点 服务器里所有"数值"都需要被记下来。金币、体力、连击数、签到状态、VIP 等级、自定义计数器，本质都是 (玩家, 键, 值) 这一组关系。各种插件各自实现一套，又会出现重复的存储层、重复的过期逻辑、重复的 PAPI 接入。 AbolethP

前言 写前端工具链的人都熟悉这套组合 Vite + Vitest + ESLint + Prettier + tsc 对吧 但是把它们装到一起 各管各的版本 各管各的配置 是不是有点烦？ 本文记录用 Vite+ 重写一个纯浏览器端的图像生成工具的过程 顺带把 GPT-Image-2 这套 OpenA

一个桌台管理系统，覆盖后端 API、Web 管理后台、微信小程序三端。这篇文章不讲业务功能列表，只讲技术选型背后的判断、架构层面的设计取舍，以及几个值得展开的工程细节。 整体架构 三端分离，各自独立部署： 后端：Go + Gin，单二进制交付，PostgreSQL + Redis Web 管理后台：

在一个 2D 矢量编辑器中，曲线渲染和裁切工具分别依赖两套不同的精度体系。渲染走自适应 tessellation，裁切走数学参数化。两者在常规缩放下表现一致，但放大到 10 倍以上时，视觉精度与逻辑精度的裂缝就暴露了——曲线出现折线感，裁切高亮超出交点，镜像侧识别错误。 这篇文章记录这三个问题的根因

桌面应用和 Web 应用有一个根本区别：桌面应用可以拥有多个操作系统窗口。用户期望确认对话框、消息提示、设置面板能作为独立窗口弹出，可以拖离主窗口范围，甚至放到另一块屏幕上。这不是 MUI Dialog 能解决的问题。 本文记录 Foundation 项目（Wails v3 + React 19 +

桌面应用最容易被低估的，不是某一个技术点，而是开局那一整组琐碎但绕不开的问题。 窗口要怎么做，启动时不能白屏，本地数据放在哪里，子进程怎么回收，对话框要不要走系统原生，语言和主题怎么切，配置文件要不要允许用户迁移。每件事单独看都不大，但如果一开始都随手处理，后面一定会在维护阶段还回来。 这篇文章记录

在 Electron 应用里做计算密集型功能时，最直接的问题通常不是“算法能不能跑”，而是“跑的时候会不会把界面拖住”。 这次优化的对象是一个几何计算阶段。它需要对一批候选参数逐个尝试，并在每次尝试时执行完整的碰撞检测和风险判断。旧实现主要跑在 TypeScript 里，逻辑是串行的：一个候选值算完

这是什么 Fast Update Server 是一个用 Go 语言写的更新服务器，主要用来给 Electron 应用分发更新。 如果你开发过 Electron 应用，可能用过 electron-updater。这个服务就是配合 electron-updater 使用的，通过 HTTP 接口提供版本

下载地址 https://github.com/Saukiya/SX-Item/releases 问题背景 Minecraft 服务器的物品系统有一个核心矛盾：配置文件是静态的，但玩家期望每次获得的物品