开源项目 on 方糖猫Blog

GeekCast vs OpenCut：两款视频编辑项目的功能对比

Mon, 13 Jul 2026 18:00:00 +0800

GeekCast vs OpenCut：两款视频编辑项目的功能对比

我个人最近开发的GeekCast GeekCast（我开发的极客口播自动化剪辑工具）, 用AI对比了开源项目 OpenCut 的功能、架构与定位差异。GeekCast 已开源，地址：https://gitee.com/soulnew/geekcast。

一、项目定位对比

维度	OpenCut	GeekCast Engine
产品形态	通用开源非线性视频编辑器（NLE），面向普通创作者	垂直的"口播自动化剪辑工具"，面向技术博主、独立开发者、播客主
核心假设	用户在时间线上手动剪辑	视频即文本：用户像编辑文档一样删除气口、静音、语气词
目标平台	Web + Desktop + Mobile（重写版目标）	Web 管理台 + Java API + Python Worker，本地或私有部署
开源协议	MIT	已开源（Gitee）

二、功能对比

功能	OpenCut（当前重写版）	OpenCut（classic）	GeekCast
视频导入/素材管理	❌ 未实现	✅ 支持	✅ 统一 `public/assets` 目录，支持原始素材、B-roll、脱水视频
时间线编辑	❌ 无时间线模型	✅ 传统时间线	✅ 文本化 timeline：`MAIN_VOICE` / `B_ROLL` / `REMOTION_TEMPLATE`
词级删除/气口分析	❌ 无	一般 NLE 手动处理	✅ Whisper 转录 + VAD，支持词级删除与多种语义块
AI 自动化	❌ 仅 README 规划	有限	✅ 转录 → LLM 生成 Master Config → 向量匹配 B-roll → WanX 生图
B-roll 覆盖	❌ 无	基础轨道叠加	✅ KEN_BURNS、PIP、FULL_SCREEN、SLIDE_IN、ZOOM_POP、MOSAIC 等 10 种展示方式
字幕/特效	❌ 无	基础字幕	✅ Remotion 模板 + 字幕动效（打字机、渐变边框、BURST 等）
音效	❌ 无	基础音频轨道	✅ segment 级音效配置，FFmpeg `adelay+amix` 混合
渲染导出	❌ 无渲染管线	客户端/云端渲染	✅ Remotion CLI 渲染 + FFmpeg 后处理
横竖屏分辨率	❌ 未涉及	通用	✅ `outputResolution` 统一配置，支持 16:9 与 9:16
插件系统	📋 规划中 plugin-first	有限	❌ 无插件机制，特效/模板硬编码
MCP / AI Agent 接口	📋 规划中	无	❌ 无
Headless / 批量渲染	📋 规划中	无	⚠️ Worker 任务队列可批量，但无公开 API/Scripting
移动端	📋 规划中	有 Web/移动端	❌ 不支持

三、技术架构对比

维度	OpenCut（重写版）	GeekCast
前端	React 19 + TanStack Router/Start + Tailwind v4 + shadcn/ui	Vue 3 + Vite + Pinia
后端	Elysia + Cloudflare Workers	Spring Boot 3 + Java 17 + MySQL + RocketMQ
桌面端	Rust + GPUI（Zed 同款）	无
核心渲染	未开始（目标：Rust core 跨 Web/Desktop/Mobile）	Python Worker + Remotion (React/TypeScript/Node) + FFmpeg
工程化	moonrepo + proto + Bun + Rust 工具链	Maven/Gradle + Python pip + Node npm
部署	Cloudflare Pages + Workers，边缘原生	本地/私有服务器，文件系统共享

四、OpenCut 优劣势

4.1 优势

开源 + 通用：MIT 协议，目标是"人人都能用的开源 Premiere/CapCut"，生态潜力大。
跨端野心：Rust core + Web/Desktop/Mobile 一套代码，若做成可避免重复开发。
AI/Agent 原生：规划了 MCP Server、Headless 模式、Scripting Tab，未来可能天然适配 AI 工作流。
现代化工具链：moonrepo、GPUI、TanStack、Elysia 都是当前较新的技术选型。

4.2 劣势

当前几乎空白：本地仓库只有 3 个空壳应用（Web 首页 Hello World、API 3 个健康检查端点、Desktop 一个窗口壳），没有实际剪辑能力。
工程风险高：Rust core 跨 Web(WASM)/Desktop/Mobile 的共享渲染、插件 ABI/WASM、移动端适配都是高难度目标，落地周期极长。
经典版割裂：README 自己都说当前能用的是另一个仓库 opencut-classic，重写版与经典版暂不兼容。

五、GeekCast 优劣势

5.1 优势

端到端可运行：从上传口播 → Whisper 转录 → 气口分析 → 精剪 → B-roll/特效/音效 → Remotion 渲染，整条链路已实现。
文本驱动降低门槛：不需要用户懂非线性剪辑，删除气口像删文字一样。
AI 链路完整：LLM 生成剧本/时间线、CLIP 向量匹配 B-roll、WanX 生图、提示词增强，自动化程度高。
视觉能力丰富：Remotion 模板、字幕动效、B-roll 多种展示方式、竖屏适配，成片风格统一。
强契约文化：ai_work/design/ 里有大量跨层契约、边界值、问题复盘，适合长期维护。

5.2 劣势

领域狭窄：只擅长"口播 → 短视频"这一类内容，无法做通用 Vlog、剧情片、多机位等复杂剪辑。
本地/Windows 中心化：很多路径、Chrome Headless、资产目录都是本地假设，难以直接 SaaS 化或多租户。
扩展性差：没有插件系统，新增特效/模板需要改 Remotion 代码并重新部署 Worker。
AI 瓶颈明显：LLM 输出 token 限制、AAC padding、B-roll 节奏等问题都依赖后处理和 prompt 调优。

六、结论与可借鉴点

你的场景	建议
想做一个通用、开源、社区化的视频编辑器	OpenCut 的方向更匹配，但要接受它目前只是脚手架，可能需要从 classic 版或自己重新设计核心。
想快速落地"口播/播客"自动剪辑	GeekCast 的架构和契约更成熟，可直接作为参考甚至基础。
GeekCast 想补齐 AI Agent / 批量渲染 / 插件能力	可以借鉴 OpenCut 规划中的 MCP Server、Headless CLI、plugin-first 架构，把 Remotion 模板做成可插拔配置。
OpenCut 想做出口播自动化功能	可以参考 GeekCast 的"视频即文本"工作流、Whisper+VAD 气口模型、Remotion+FFmpeg 渲染管线。

简而言之：OpenCut 是"想做通用编辑器的宏大蓝图"，GeekCast 是"在口播自动剪辑这个细分领域已经跑通的工程实现"。两者目前不在同一个完成度层级上，但互相有不少可借鉴的设计理念。

如果你在视频自动化、AI 剪辑或多模态生成方面有想法，欢迎在评论区交流。

starmall：一个微信小程序电商系统的全栈实战——预约、支付与订单架构解析

Tue, 20 Jul 2021 10:00:00 +0800

starmall：一个微信小程序电商系统的全栈实战——预约、支付与订单架构解析

这是我 2021 年做的一套完整电商系统 starmall（六爻星辰）：微信小程序端 + Java 后端 + PC 管理后台，支持商品购买、老师咨询时段预约、择吉日查询、在线咨询等业务。整理开源出来，写篇文章做一次完整的技术复盘。

前端（uni-app 小程序）：https://gitee.com/soulnew/starmall
后端（Java + 管理端）：https://gitee.com/soulnew/crm_server
技术栈：Spring Boot 2.2 + MyBatis-Plus + MySQL + Redis / uni-app + uView / Vue 2 + Element UI（管理端）
说明：后端是在开源商城 CRMEB Java 版 基础上二次开发的，分销/秒杀/拼团/砍价等营销能力来自底座，预约系统、择吉日、名片、咨询聊天等是自研部分

一、整体架构

graph TD
    MP["微信小程序端<br/>starmall uni-app + uView"] -->|"https://ftmao.com/api/front/**"| API["SpringBoot 单体后端<br/>62 个 Mapper / 23 个前台 Controller"]
    H5["H5 / App<br/>uni-app 多端编译"] --> API
    ADMIN["PC 管理后台<br/>Vue 2 + Element UI + ECharts"] -->|"后台接口"| API
    API --> MYSQL["MySQL 5.7<br/>62 张表 Druid 连接池"]
    API --> REDIS["Redis<br/>token / 订单缓存 / 任务队列 / 配置缓存"]
    API --> WX["微信开放平台<br/>登录 / 支付 V2 / 订阅消息"]
    API --> QN["七牛云 OSS<br/>图片上传"]
    API --> QY["企业微信机器人<br/>部署结果通知"]
    MP -->|"wss://... websocket"| CHAT["咨询聊天服务"]

代码规模：后端约 850 个 Java 文件、12.6 万行；小程序前端业务代码约 1.2 万行；数据库初始化 SQL 全量在仓库里，共 62 张表。后端按业务分包：front（小程序接口）、order/payment、marketing、seckill、task（定时任务）、wechat，以及自研的 appoint（预约）、lunar（黄历）等模块。

二、功能介绍

2.1 商品购买全流程

标准的商城闭环：商品详情（多规格 SKU）→ 立即购买/加购物车 → 确认订单（优惠券、积分抵扣、运费计算）→ 创建订单 → 微信支付 → 轮询支付结果 → 收货评价 → 退款/售后。支付是真实对接的微信支付 V2——后端手工实现 XML 报文 + MD5 签名调统一下单（WeChatPayServiceImpl，746 行），前端弹起 wx.requestPayment，不是 mock。

此外还支持：余额支付、运费模板（满额包邮/指定城市包邮/按件数重量体积三种首续费）、物流查询、自提核销码、再次下单。营销玩法（秒杀、砍价、拼团、优惠券）来自 CRMEB 底座，一应俱全。

2.2 老师咨询时段预约（自研核心）

这是这个项目区别于普通商城的地方——卖的不只是实物商品，还有"老师的时间"：

商品分类为"老师类"时，商品详情页出现一个时段选择器（每天 6 个时段：9/11/13/15/17/19 点）；
teacher_plan 表按「日期 × 时段」预生成号源，被约走的时段前端置灰；
下单时携带 teacherPlanId，创建订单的同一个事务里把该时段标记为已约——号源占用和订单创建要么一起成功要么一起回滚，不会出现"钱付了时段没了"；
号源由定时任务 TeacherPlanTask 每 8 小时自动向前补齐未来 8 天，并清理过期的空闲号源。

2.3 其他自研功能

择吉日查询：4.7 万行黄历数据入库（lunar 系列表），按"宜"事反查吉日，比如查"最近适合搬家的日子"；
在线咨询：基于 WebSocket 长连接的实时聊天，支持文字/语音/图片消息（详见第三章「长连接聊天」）；
老师名片、文章资讯、签到积分、充值、小程序订阅消息提醒；
管理后台：商品/订单/营销/分销/财务/短信/按钮级权限/数据统计大屏（ECharts）。

三、后端能力全景

后端虽然是 SpringBoot 单体，但能力面相当完整：前台 23 个 Controller、62 个 MyBatis Mapper，按业务分包组织：

graph TD
    subgraph M1["业务模块"]
        A1["front 前台接口<br/>23 个 Controller"]
        A2["order / payment<br/>订单与支付"]
        A3["marketing / seckill / bargain / combination<br/>优惠券 秒杀 砍价 拼团"]
        A4["appoint / lunar / businessCard<br/>预约 择吉日 名片（自研）"]
        A5["finance / statistics / export<br/>充值提现 数据统计 Excel 导出"]
        A6["wechat / wechatMessage / sms<br/>微信生态与短信"]
        A7["task<br/>定时任务体系"]
    end
    subgraph M2["公共层"]
        B1["拦截器链<br/>前台 Token / 后台 Token+权限 / Swagger"]
        B2["工具层 RedisUtil / WxPayUtil / CrmebUtil"]
        B3["ThreadLocal 上下文传递当前用户"]
    end
    A1 --> B1
    A2 --> B2
    B1 --> B3

商城主链路之外，后端还有一批容易被忽略的能力：

微信公众号消息自动回复：wechatMessage 模块支持文字/语音/图片/图文四种回复类型，关注、取关、扫码等事件都有对应处理；
模板消息与订阅消息：小程序订阅消息、公众号模板消息的增删查与群发，且发送走异步任务（AsyncWeChatProgramTempMessage 等），不阻塞主流程；
渠道二维码与素材管理：带参数的推广二维码、微信素材的上传管理；
数据导出与统计：POI 实现的 Excel 导出、交易/商品/用户多维统计接口（配合管理端 ECharts 大屏）；
短信与物流：短信验证码/通知、快递物流轨迹查询；
接口文档：Swagger 在线文档 + 仓库内置 admin/app/公共三份离线接口文档。

3.1 长连接聊天（WebSocket）架构

在线咨询是这个系统的"第二前台"，采用的是 WebSocket 长连接 + HTTP 接口的组合方案。部署上两个服务跑在同一台服务器，由 nginx 按路径前缀分流：

graph TD
    MP["小程序聊天页<br/>pages/chat"] -->|"wss://.../websocket/userId/sessionId"| NGX["nginx 按路径分流"]
    MP -->|"HTTP /chat/session/**  /chat/msg/**"| NGX
    MP -->|"HTTP /api/front/**"| NGX
    NGX --> CHAT["聊天服务<br/>WebSocket 长连接 + 会话/消息接口"]
    NGX --> MALL["商城后端 crm_server<br/>SpringBoot 18080"]

从开源的小程序端实现和接口契约，可以看到这套长连接聊天的几个设计要点：

连接即身份：WebSocket 握手 URL 直接携带 userId/sessionId，连接建立的同时就完成了身份识别与会话路由，不需要额外的登录帧；
实时走长连接，持久化走 HTTP：收发消息走 WebSocket（消息体为 JSON）；会话绑定（session/bindSession）、会话列表、删除会话、历史消息拉取（msg/msgList）都走 /chat/ 前缀的 HTTP 接口——长连接管"实时推送"，HTTP 管"可查询、可回溯"，职责分得很干净；
统一的消息类型协议：contentType 1=文字、2=语音（带 contentDuration 时长）、3=图片（先经 user/upload/image 上传拿到 URL，再把 URL 作为消息内容发出）；
语音消息的移动端交互：按住说话（touchstart/touchend 控制录音起止）、上滑取消（touchmove/touchcancel），体验和微信原生聊天对齐；
发送体验乐观化：消息发出后先本地 push 进消息列表立即上屏，send 的 fail 回调再 toast 兜底提示。

需要如实说明：聊天服务端的代码没有随这两个仓库开源（它部署在同一台服务器上，由 nginx 分流），仓库里能看到的生产实现是小程序端；crm_server 里的 com/im/SocketServer.java 只是当时练手的原生 TCP Socket demo（12345 端口），并非线上实现。

四、技术亮点

4.1 下单幂等：两段式 + 唯一键兜底

小程序网络环境下用户双击、重试、断网重发是常态，下单接口必须幂等。这里用了一个两段式设计：

graph TD
    A["order/confirm 确认订单页"] --> B["订单数据序列化存 Redis<br/>key = md5 当前时间<br/>有效期 60 分钟"]
    B --> C["order/create/orderKey 创建订单"]
    C --> D{"第一步:查库判重<br/>StoreOrder.unique = orderKey"}
    D -->|"已存在"| E["直接返回已有订单<br/>不重复创建"]
    D -->|"不存在"| F{"第二步:校验 Redis 缓存<br/>是否过期/被用过"}
    F -->|"过期"| G["拒绝 提示重新确认"]
    F -->|"有效"| H["事务内创建订单<br/>成功后删除缓存"]

unique 字段是最后的兜底——即使 Redis 挂了、缓存丢了，数据库唯一约束也保证同一个 orderKey 不会建出两张单。

4.2 原子扣库存防超卖

库存扣减没有用"先查后改"，而是一条 SQL 完成：

// setSql + 条件改写，数据库层面原子完成
stock = stock - n   且要求   stock - n >= 0

数据库单行更新的原子性天然挡住并发超卖，不需要分布式锁。秒杀/砍价/拼团场景更复杂：同一事务内要扣活动表 + 活动 SKU 表 + 商品表 + 商品 SKU 表四份库存，任何一步失败整体回滚。

4.3 编程式事务包住整个建单过程

创建订单是个多写操作：扣库存、占预约时段、写订单主表、写订单详情、核销优惠券、写订单日志。代码用 TransactionTemplate 编程式事务（而不是 @Transactional 注解）把这一串操作包起来——好处是事务边界精确可控，不会把整个方法（包括不需要事务的远程调用）都圈进去。订单核心逻辑集中在 OrderUtils.java（1500+ 行）和 OrderServiceImpl.java（近 1000 行）。

4.4 支付回调：防重 + 异步化

微信支付的回调处理（CallbackServiceImpl.weChat，448 行）有几个关键点：

解析 XML、校验 return_code/result_code，按 attach 里携带的 userId + type 区分是订单支付还是充值；
已支付直接返回 SUCCESS——微信会多次重推回调，幂等是回调接口的生死线；
事务内完成 updatePaid（置订单已支付）+ 扣积分 + 拼团状态处理；
后续的"慢动作"——发短信、推订阅消息、分销结算——不放在回调里同步做，而是 lPush 进 Redis 队列异步执行，回调接口尽快给微信返回，避免超时重推。

4.5 没有 MQ：Redis List + 定时任务的务实替代

项目没有引入 RabbitMQ/RocketMQ，而是用 Redis List 当队列 + Spring @Scheduled 定时任务消费，撑起了一整套异步任务体系：

graph LR
    A["下单成功<br/>lPush ORDER_AUTO_CANCEL_KEY"] --> Q["Redis List 队列"]
    P["支付成功回调<br/>lPush 后续动作"] --> Q
    Q --> T1["OrderAutoCancelTask<br/>每分钟消费<br/>超时未支付自动取消 + 回滚库存"]
    Q --> T2["自动收货 / 自动好评"]
    Q --> T3["优惠券过期 / 砍价截止<br/>佣金解冻"]
    Q --> T4["TeacherPlanTask<br/>每8小时补齐号源"]

task/order/ 下共有 8 个定时任务。对这个体量的系统，省掉一个 MQ 的部署运维成本，换来的是完全够用的可靠性——这是小项目技术选型上我很认可的一个取舍。

4.6 鉴权链路：UUID Token + Redis + ThreadLocal

没有用 JWT，而是更传统的方案：登录后签发 UUID 存 Redis（按模块区分 key 前缀），拦截器 FrontTokenInterceptor → CheckFrontToken → TokenManagerImpl 逐级校验，通过后把当前用户放进 ThreadLocal 供全链路取用。管理端是 Token + 权限双拦截器。好处是服务端可随时踢人下线（删 Redis key 即可），这是纯 JWT 做不到的。

4.7 其他值得提的实现

订单快照：下单时把购物车内容序列化成 JSON 存进 StoreOrderInfo.info，之后商品改价改名都不影响历史订单的展示；
运费计算引擎：getOrderPriceGroup 支持满额包邮、指定城市包邮（件数 + 金额双条件）、按件数/重量/体积三种首续计费模式；
XSS 转义：用户输入统一 escapeHtml4；
部署脚本：start.sh nohup 启动 + 轮询日志判断启动成功 + 企业微信机器人推送部署结果——单机部署也搞出了仪式感。

五、复盘与遗憾

底座与自研的边界：秒杀/拼团/砍价/分销这些"重"能力直接复用 CRMEB 底座，把精力集中在业务差异化（预约、择吉日、聊天）上——对个人开发者来说这是正确的杠杆；
单体的局限：所有东西在一个 SpringBoot 应用里，定时任务、支付、前台接口互相影响，量大了必然要拆；
原子扣库存的返回值没检查：setSql 扣减失败（库存不足）时影响的行数为 0，但代码没有校验这个返回值，极端情况下会漏判超卖——这是现在回头看想补的一个洞；
聊天服务端未开源：如第三章所述，长连接聊天的服务端实现没有随仓库开源，小程序端和接口契约是完整的，算是开源的一点遗憾。

六、写在最后

这个项目让我完整走了一遍"真实收钱"的系统该有的样子：幂等、事务、防超卖、回调防重、异步补偿——每一个点背后都是电商系统趟过的坑。代码在 https://gitee.com/soulnew/starmall 和 https://gitee.com/soulnew/crm_server，建库 SQL、接口文档都在仓库里，希望能给做小程序商城的朋友一个可参照的完整样本。

jphotoshop：用 Java Swing 手写一个 Photoshop——架构与算法全解析

Fri, 18 May 2018 10:00:00 +0800

jphotoshop：用 Java Swing 手写一个 Photoshop——架构与算法全解析

把多年前的一个练手项目整理开源了：jphotoshop，一个用纯 Java Swing 手写的 Photoshop 模拟器。不写不知道，写一个"简化版 PS"几乎把计算机图形学、数据结构和设计模式都过了一遍，这篇文章既是功能介绍，也是一次技术复盘。

开源地址：https://gitee.com/soulnew/jphotoshop
技术栈：Java + Swing（Swing Application Framework / JSR-296），NetBeans Ant 工程
规模：197 个 Java 文件，约 1.8 万行（自研约 1.4 万行），开发周期约半年

一、功能概览：一个"简化版 PS"能做什么

UI 形态上和老版 PS 一致：MDI 多文档界面——每张图片一个内部编辑窗口，图层面板、导航缩放面板都是可拖动的浮动内窗。

1.1 图层系统

多图层编辑：图像图层、文字图层、浮动选区层（拖动选区内容时的临时层）；
图层面板带 40×30 实时缩略图，支持拖拽换序（基于 Swing TransferHandler 的 DnD）、复制粘贴为新图层；
透明区域用经典的灰白棋盘格打底。

1.2 选区工具（7 个）

工具	说明
魔棒	容差可调（默认 23），支持多连通区域一次选中
色彩范围	全图相似色选取
多边形套索	逐点勾勒
自由套索	鼠标轨迹勾勒
磁性套索	局部窗口内吸附边缘（完成度不高）
贝塞尔选区	双击闭合时自动做曲线拟合，生成平滑选区
移动工具	把选区内容提成浮动层，拖动实时合成，松手落回底层

选区还支持：羽化（可调半径）、反选、平移/缩放（AffineTransform）、以及标志性的蚂蚁线动画。

1.3 滤镜（24 个，分 5 大类）

模糊：均值平滑、高斯模糊（3×3 高斯核 {1,2,1;2,4,2;1,2,1}/16）、中值滤波；
锐化：Sharpen / SharpenMore（拉普拉斯卷积核 {0,-1,0;-1,5,-1;0,-1,0}）；
艺术：曝光过度、冰晶、熔岩、暗调（平方衰减）、漫画等 8 种风格化效果；
简单：反色、怀旧（sepia 矩阵 0.393/0.769/0.189...）、灰度；
扭曲：挤压、球面化、正/反旋转、正弦波浪、摩尔纹——扭曲类全部带多段滑块实时预览，取消可还原。

1.4 图像调整与文字

HSB 调整：先把整图 RGB 转成 HSB 三维 float 数组，色相/饱和度/亮度三个滑块实时调节再转回 RGB；
对比度调整；
文字工具：点击图片任意位置就地出现透明输入框 + 字体选择面板，完成后生成为独立的文字图层。

1.5 文件与工程

打开 jpg / png / gif / bmp；
自定义 .jps 工程格式（类似 PSD）：整个图层模型实现 Serializable，用 ObjectOutputStream 套 GZIPOutputStream 序列化保存，可以随时回来继续编辑；
复制 / 剪切 / 粘贴、导航缩放窗口、中文界面。

二、架构总览

graph TD
    A["JPhotoShop 入口<br/>EDT 中构建主窗口"] --> B["JDesktopPane MDI 主框架"]
    B --> C["EditFrame 编辑窗口<br/>每张图一个"]
    B --> D["LayerControl 图层面板"]
    B --> E["ViewSizeFrame 导航/缩放"]
    C --> F["EditModel<br/>像素模型 + MemoryImageSource 渲染"]
    F --> G["ImageModel<br/>LinkedList 图层栈"]
    G --> H["ImagePaintLayer / TextPaintLayer / TempImageLayer"]
    H --> I["LayerPlug 混合样式<br/>Alpha 合成"]
    C --> J["ToolManager<br/>工具代理/状态切换"]
    J --> K["Tool 抽象类<br/>魔棒/套索/贝塞尔/移动/文字..."]
    C --> L["FilterManager<br/>properties + 反射装配"]
    L --> M["PicFilter 滤镜即 Action"]
    M --> N["Math 包<br/>CoverOp 卷积 / FeatherSide 羽化<br/>FindSide 轮廓追踪 / PointConnection 并查集"]

整体分四层：UI 层（MDI 窗口与面板）、模型层（图层栈与像素数据）、工具/滤镜层（操作入口）、算法层（jphotoshop.Math 包）。工具和滤镜都通过 properties 配置 + 反射装配，下面详细说。

三、技术亮点

3.1 自绘像素管线：int[][] + MemoryImageSource

核心存储没有用 BufferedImage，而是直接操作 int[][] ARGB 二维数组——所有算法（卷积、混合、羽化）都在裸数组上做，直观且没有额外封装开销。

显示侧用了一个当年很典型的 Swing 高性能技巧：MemoryImageSource + setAnimated(true)，像素变化后调 newPixels() 增量刷新屏幕图像，避免每次重绘都重建整个 Image 对象。编辑、拖选区、调滤镜滑块时的实时反馈都靠它撑着。

3.2 链式图层合成缓存

多图层合成是最频繁的操作，朴素实现是每次重绘把所有层从头合一遍。这里的做法是给每个图层挂一个"本层与下面所有层合成结果的缓存 cacheData"，层与层之间用 backLayer 引用连成链：

graph LR
    BG["背景层<br/>棋盘格"] -->|"合成"| L1["图层1<br/>cacheData"]
    L1 -->|"合成"| L2["图层2<br/>cacheData"]
    L2 -->|"合成"| L3["图层3<br/>cacheData"]
    L3 --> OUT["最终显示图像"]
    style L2 fill:#f96
    L2 -. "仅从此层向上重建" .-> L3

某一层像素变化时，只从该层向上依次 reBuild，下面的层缓存不动。层数多、图大时，这个收益非常明显。

3.3 手写 Alpha 混合

AlphaLayerStyle 实现了逐像素的经典混合公式 C = α·Cf + (1-α)·Cb，并且处理了任意偏移（含负坐标裁剪）——浮动选区拖到画布边缘外也能正确合成。羽化后的选区掩码是 short 型 alpha 权重，抠图粘贴时按权重衰减，边缘不会出现生硬的锯齿。

3.4 魔棒：一条完整的算法链

魔棒是整个项目里算法含量最高的功能，完整链路分三步：

graph TD
    A["用户点击图片某点"] --> B["Flood Fill 泛洪填充<br/>8邻域 + 容差判断<br/>ΔR+ΔG+ΔB ＜ range"]
    B --> C["PointConnection 并查集<br/>id 数组 + sz 数组按秩合并<br/>分离多个互不连通的区域"]
    C --> D["FindSide 8方向轮廓追踪<br/>沿区域边界走一圈<br/>每3步抽稀路径点"]
    D --> E["GeneralPath 选区路径"]
    E --> F["蚂蚁线动画<br/>Timer 500ms 切换两条相位差3的虚线"]

几个细节：

泛洪填充用 LinkedList 当队列，容差判断用曼哈顿距离（|ΔR|+|ΔG|+|ΔB|），比欧氏距离省开方；
一次点击可能选中多个互不连通的区域（比如图片里分散的几块蓝天），用并查集把连通域分组，每个域独立生成轮廓；
轮廓追踪把面状的 boolean 掩码转成线状的路径点列，这一步直接决定蚂蚁线的平滑程度；
蚂蚁线动画是两条相位差为 3 的虚线 BasicStroke 用 500ms 的 Timer 交替绘制——朴素但效果完全对味。

3.5 通用卷积引擎 CoverOp

所有卷积类滤镜（模糊、锐化背后是同一个引擎 CoverOp，提供三种重载：

全图卷积；
掩码限定区域卷积——滤镜只在选区内生效，这是 PS 的基本体验；
short alpha 掩码卷积——配合羽化选区做渐变处理。

RGB 三通道分离卷积 + 边界 clamp，滤镜类只需要给一个卷积核就完事。新增一个模糊变体的成本是十几行代码。

3.6 贝塞尔选区：Schneider 曲线拟合

自由手绘的选区轨迹是抖动的折线，直接当选区很难看。贝塞尔选区工具在双击闭合时调用 JHotDraw 的 Bezier.fitCurve（Schneider 的经典拟合算法），把鼠标点列拟合成平滑的三次贝塞尔曲线段——这就是 PS 里"钢笔工具"的底层原理。

3.7 声明式装配：properties + 反射的原始"插件化"

工具和滤镜都不写死在代码里，而是从 properties 读类名、Class.forName 反射实例化：

# resource/filters.properties
filters.Kinds=模糊,锐化,艺术效果,简单,扭曲
模糊=Smooth,GaussBlur,Median

加一个新滤镜 = 写一个类 + 改一行配置，菜单自动按分类分组生成。工具栏同理（ToolManager.initTool）。项目里还专门有一个 plug 包在探索真正的外部插件机制（虽然只是个雏形）。在 2007 年没有 OSGi、没有 IoC 框架依赖的纯 Swing 工程里，这是最务实的可扩展方案。

3.8 工具架构：Proxy + State 的混合

Tool 抽象类把底层 MouseEvent 翻译成语义化回调（click / pressed / dragged / release / rightClick / clickDouble / move），子类只关心语义。ToolManager 本身也是 Tool 的子类，作为代理把事件转发给当前激活的工具——选中哪个工具，事件流就切到哪个状态机上。每个工具还可以自带 getPlugPanel() 参数面板，选中时挂到选项栏上，和 PS 的交互完全一致。

3.9 扭曲滤镜的"预览-取消"模式

扭曲类滤镜（球面、旋转、波浪……）都是坐标重映射：对每个目标像素做逆极坐标变换，找它在原图的取样点。为了支持滑块实时预览又能取消还原，ContortFilter 在打开对话框时先备份 tempData，滑块每次变化都在备份基础上重算，点取消直接把备份拷回——一个廉价的 Memento 模式。配套的 MultiSlider 多段滑块控件也是自绘的。

3.10 滤镜即 Action

PicFilter extends AbstractAction，滤镜本身就是可以挂进菜单/工具栏的 Action：actionPerformed 里自动取当前窗口、当前图层、当前选区掩码，还处理了选区坐标系到图层坐标系的换算（start -= layerStart），执行完触发 rePaintEdit 刷新。框架把脏活都干了，滤镜作者只需要关注像素算法。

四、诚实的复盘：留下了什么遗憾

开源的代码就是当年的样子，包括未完成的部分，如实列出：

撤销/重做是空架子：UndoRedoManager 的骨架搭好了，但 propertyChange 三个分支全是空的——这是当时没啃下来的硬骨头，现在看应该用 Command 模式重做，而不是当初设想的 property 监听方案；
历史面板、通道面板、外部插件机制都只有雏形；
磁性套索完成度不高；
若干小 bug，比如 FindSide 里找最近点写成了找最远点（if (temp > MinLength) 应为 <）、"undo".endsWith(...) 应为 startsWith、几处类名 typo（WaveFiler、getSize 拼写）——权当留给读者的"考古彩蛋"。

五、写在最后

写 jphotoshop 的半年收获远超预期：并查集、轮廓追踪、卷积、贝塞尔拟合这些算法不再是教科书上的名词，而是要亲手调到能跑的东西；合成缓存、声明式装配、Action 抽象这些设计，也都是被真实需求逼出来的。如果你也想扎实练一次"算法 + 工程"的综合功，手写一个图像编辑器是我能想到的最好题目之一。

源码在 https://gitee.com/soulnew/jphotoshop，欢迎 Star、Fork，更欢迎把那个空着的 UndoRedoManager 补上。