标签 二次开发 下的文章

一、概述总结

餐饮茶馆预约预订桌小程序是千行科技开发的一款专注于餐饮娱乐行业的智能预约解决方案。该系统以微信小程序为载体，集成于微擎开放平台生态，为餐厅、茶馆、咖啡厅、奶茶店、酒吧等实体店铺提供完整的线上预约、订座、会员营销一体化服务。

产品采用微擎系统交付模式，源码未加密，支持PHP 7.1-7.4版本，便于二次开发与定制。系统通过灵活的时间场次设置、自定义收费字段、多级会员体系等核心功能，帮助商家实现0等待到店、精准客流管理、会员忠诚度提升三大经营目标，是线下实体门店数字化转型的轻量级高效工具。

二、功能介绍

  1. 智能预约预订核心功能
  • 多渠道预订入口：顾客通过微信小程序随时随地在线选桌、订座
  • 实时桌台状态：可视化展示空闲、已预订、使用中等桌台状态，避免重复预订
  • 预约时段精准控制：商家可自定义设置可预约时间段（如11:00-14:00, 17:00-21:00）
  • 时长灵活配置：支持设置不同时长选项（如2小时、3小时、不限时），适配不同业态需求
  1. 自定义字段与收费体系
  • 动态字段添加：可根据业务需求添加特殊要求字段（如包间偏好、菜品预留、特殊布置等）
  • 增值服务收费：对定制化需求设置附加费用（如包间费、景观位费、套餐绑定等）
  • 预约金/定金模式：支持设置预订保证金，降低顾客爽约率
  1. 多级会员营销系统

  • 普通会员体系：

    • 累计消费次数自动升级（如消费满10次升级银会员）
    • 等级折扣权益，提升用户复购率

  • 店铺VIP会员：

    • 独立VIP开通功能，享受专属折扣或免费预约权益
    • 本店消费达标自动成为VIP，增强客户粘性
    • 差异化定价策略，实现高价值客户精细化运营
  1. 后台管理中枢
  • 预约订单管理：实时查看、确认、取消预约订单，支持短信/模板消息通知
  • 数据统计分析：预约转化率、时段利用率、会员消费行为等多维度数据报表
  • 规则灵活配置：营业时间、可约天数、取消政策等参数自定义
  • 多门店支持：适配连锁品牌多店铺管理模式（需扩展开发）

三、适用场景与行业价值

适用场景

行业类型 具体场景 核心价值点

正餐餐饮 中餐厅、火锅、烧烤、日料等 高峰时段分流、大桌提前锁定、降低等位流失率

茶饮空间 茶馆、茶艺馆、棋牌茶室 包间时段管理、按位收费、长时消费预约

轻食咖啡 咖啡厅、奶茶店、甜品店 景观位预订、团体聚会预留、会员专享座

夜场娱乐 酒吧、清吧、Livehouse 卡座预订、低消设置、VIP快速通道

多元业态 融合餐厅、餐吧、书吧 混合时段计费、区域差异化管理

行业价值

对商家：

  • 降本增效：减少电话接听人力成本，降低空桌率15-30%
  • 精准运营：通过预约数据预测客流，优化排班与食材备货
  • 锁客增频：会员体系提升复购率，VIP机制筛选高价值客户
  • 体验升级：顾客免排队等待，提升品牌好感度与口碑传播

对顾客：

  • 确定性保障：提前锁定座位，避免到店无座的糟糕体验
  • 时间自由：可视化选择最便利时段，灵活安排行程
  • 权益感知：会员折扣与专属服务增强消费仪式感与归属感

四、常见问题解答（QA）

Q1：购买后是否包含小程序源码？后续可以二次开发吗？

A：本产品交付方式为在线交付，源码未加密，购买后可获得完整源代码。支持在PHP 7.1-7.4环境下进行二次开发与功能定制，满足个性化业务需求。

Q2：是否支持抖音小程序或其他平台？

A：当前版本仅支持微信小程序。如需抖音小程序、支付宝小程序等多平台版本，需联系开发者进行定制开发，或使用微擎系统的多端适配能力自行扩展。

Q3：预约功能能否设置"开场前2小时不可取消"这类规则？

A：系统支持灵活的取消政策配置。商家可在后台设置免费取消截止时间，过后取消可设置扣费规则或不允许取消，有效降低顾客爽约带来的损失。

Q4：VIP会员功能如何与商家现有会员系统打通？

A：本系统内置独立会员体系。如需打通商户现有CRM或收银系统会员，需通过API对接或数据库映射进行二次开发。微擎开放生态提供标准接口规范，开发成本相对较低。

Q5：小程序是否需要单独购买服务器和域名？

A：需要。本产品为微擎系统应用模块，需自行准备服务器、域名并安装微擎框架。建议选择微擎云市场推荐的配置，确保系统稳定运行。

Q6：是否支持多个门店独立管理？

A：基础版本支持单门店管理。多门店版本需要额外开发或购买多店插件。微擎平台有多款多门店管理工具可配合使用，具体可咨询开发者获取整合方案。

最近逛帖子，看到好多人想集成低代码，但是不是市面上那种 saas，想要私有化部署，并且支持二开的，，，我想到我最近写的这个了，想分享出来，但是又怕各位大佬说缺失基础功能啥的，我写的这个只是实现了部分核心功能，算了说我就说我吧，我脸皮厚，希望能帮助到大家。有什么不足的功能或者建议欢迎交流，我也会继续努力的。

分享我写的一套自研工作流引擎，低代码底座模型源码1

上一波地址，知录 AdminAdmin

📌 转载信息
原作者：
zhongmeishi
转载时间：
2026/1/23 10:20:16

本文由TinyPro中后台系统贡献者周泽龙原创。

在长达三个月的开发下，终于TinyPro的Springboot后端版本终于要问世了，在本期内容中我将带大家一步步去搭建整个后端的流程，也将带大家去探索对于最新版本的更改应该如何实现，以及如何使用本项目进行一个二次的开发和探索。
首先我们先要对于TinyPro项目进行一个整体的拉取，去到TinyPro的官方进行拉取，当我们获取到项目以后就可以进行开始今天的项目构建了。

接下来的流程就是对于前端i项目的搭建以及后端的springboot项目的搭建，最后再去介绍咱们新版本里面的一些特性和组件

1.前端部分的搭建

首先要确保咱们安装了Node.js、NPM、TinyCLI接下来就要正式初始化项目了首先我们进行初始化

(1)在命令行输入tiny init pro对项目进行一个初始化具体的流程可以看我的视频介绍

1.jpg
(2)接下来就让我们进入到我们的项目里面，tinyvue的前端代码里面我们首先进行一个项目的依赖的下载大家可以使用npm install进行项目依赖的下载。

(3)当我们项目依赖下载完成后就可以进入到一个启动流程了，使用npm start进行一个项目的启动启动后就会开启3031端口这样就可以看见项目的启动界面了!

2.png

到目前为止我们的前端项目就算正式启动成功了，接下来让我们一起开始启动后端项目

2.后端项目的搭建

首先我们需要确保自己的本地环境里面有jdk17，maven,mysql,redis以及一个自己喜欢的开发软件可以idea或者vscode

好了准备工作做好以后接下来就让我们进入后端的开发和后端二次开发的一个介绍并且我也将带着大家去了解springboot里面的一些设计和里面的一些函数的内容接下来开始吧

项目结构的介绍：
当进入到项目里面的时候我们最直观的可以看见项目的一个整体结构

3.png
（1）先介绍一下项目的一个配置文件，对于所有的springboot项目上来第一件事就算看配置文件application.properties文件这个文件里面包含了所有项目需要的配置比如：mysql,redis,Springjpa,mybatis-plus(项目里面没有使用，但是基本的配置都配置好了，也就兼容了喜欢使用mybatis-plus的同学）大家可以更具自己的数据库信息和redis进行配置，需要自己填写好数据库的用户名，端口和驱动地址，还有redis的配置信息比如主机地址和端口号

到这里的同学，那就恭喜大家数据服务的配置我们就是做好了，接下来就是对项目的依赖的下载，这块主要涉及到maven的使用，如果还，没有下载maven的同学记得赶快去下载

（2）接下来开始项目依赖的初始化过程，在项目启动的时候，我们需要先对项目的依赖包去官方的仓库里面下载(这块给大家一个提醒，如果下载过慢的同学记得去配置一下maven的国内镜像源进行下载和配置),敲入命令
mvn install进行一个项目依赖的下载。

如果到这里都执行成功，大家就可以正式的启动项目，正式启动项目之前我希望大家可以去查看自己jdk的配置是否是17，因为接下来的必须要使用jdk17了

（3）进入到TinyProApplication文件里面进行启动项目，在这之前需要确保启动了redis和mysql的服务，并且配置好了密码，然后启动项目以后我们就会看到一个提示：

4.png
这里就算证明项目的整体正式启动成功了，接下来就开始监听3000端口了。

项目启动成功以后就可以开始进行一个交互了，大家就可以进入到刚才启动的前端项目里面准备进行一个交互，账户和密码都是admin，这块是配置里面预先写好的，如果有人需要修改这个用户和角色名称，可以进到 DataInitializer文件里面找到user配置进行修改

3.二次开发的讲解

首选项目里面可以进行二次开发的地方就算，权限管理，拒绝策略，以及用户的登录校验，初始化配置

5.png

（1）首先就是项目的权限管理的问题大家可以看见代码里面首先需要权限校验的接口上面都会有一个

6.png
@PermissionAnnotation这个注解里面配置的就是当前接口需要用户所拥有的权限，然后这块里面底层的实现细节在aspect这个目录里面，然后里面就是对于apo的一个使用。如果大家需要给某一个接口增加新的权限大家就可以直接在接口的上面进行一个使用然后写入具体要限制的细节
比如可以写：

7.png
这块就是要求用户必须要有menu::query::list这个权限才能进入到这个接口里面进行查询操作如果大家想更进一步了解到权限管理的细节，可以去看aop的使用java里面的切面编程

（2）接下来可以看拒绝的策略，首先对于接口拒绝策略的具体控制在配置文件里面，大家可以看到

8.PNG
这块就是一个拒绝策略的开关，如果大家想开始拒绝策略就可以直接输入true这个然后就会开启拒绝策略进行项目模式，目前是默认在演示模式里面

这个里面主要分为一个演示模式和一个项目模式，在项目模式里面大家可以自由的进行控制但是在演示模式里面，有很多的功能都被禁止了，所以大家要是不能使用的话就需要先查看是否是因为在演示模式里面导致的

（3）接下来就是用户的登录校验，大家首先要明白的一个流程就是用户首先要登录，只有登录成功以后才会将token放到redis里面，然后用户登录的校验就会先去redis里面进行查询，如果查询的到就会通过校验，如果redis里面没有当前用户人的信息就会进行一个拒绝的返回，然后就会跳转到前端的登录界面里面进行一个登录。具体就是拿一个拦截器进行拦截然后对每一个请求都进行校验只有登录过的才能进行项目的操作
（4）项目的初始化整个项目的初始化都在DataInitializer.java这个文件里面，如果后续需要进行一个项目的初始化调整，比如更改初始化的顺序以及在初始化的过程中想再加载一些资源都可以在这个文件里面进行增加

9.png

在这个run方法里面进行添加，这样项目在启动的时候就会先去加载项目里面的内容然后生成一个data文件夹的，这就标志着项目以及初始化过了，不需要再进行初始化，接下来每次的项目初始化都会先去看项目里面是否有data的目录如果存在就不走初始化的逻辑了

好了讲解完二次开发以后，接下来就要进入到docker的一个部署流程，在这个之前，大家可以更具的自己的情况去看是去买一个云服务器还是自己搭建一个虚拟机环境，然后进行配置，我在视频里面给搭建演示的就是在自己的虚拟机里面进行一个docker的部署和调用

4.docker的部署讲解

首先要了解在进行docker部署的时候，自己的容器文件里面的内容是否创建好了，以及对应的docker-compose.yml的一个配置

再检查完这些内容以后就要进入到我们的一个docker的部署流程环节，其实本质上也很简单就是进入到项目的文件夹目录里面，然后直接执行docker compose up -d这个命令以后，等待下载，但是下载的过程里面会有很多的问题比如下载过慢问题

（1）将项目的文件上传到服务器上面

10.png

然后进入当前目录大家可以看见，项目里面有两个文件一个是Dockerfile另一个是docker-compose.yml着两个文件是我们必须要的文件，进入进去看见

11.png

里面就是一些配置比如mysql的地址以及redis的地址，都是对应着我们即将启动的容器名称

（2）接下来就开始正式的启动docker-compose.yml文件，使用命令docker compose up -d启动成功以后就可以进行前端端口的配置映射到线上的docker地址，方便未来的开发
12.png

这个就是启动成功了，大家可以看映射的地址进行修改前端的配置了

5.本次参加开源之夏的感受和收获

在参加完这次的开源之夏以后，我最大的感受就是第一次有一个整齐的计划和老师还有别的学校的同学们可以一起开发一个软件，让我还没出社会的时候就已经拥有了独立开发的经验和经历。其次就是老师的辅导和社区的教导让我真的成长了很多，我特别感谢开源之夏和+OpenTiny社区对我的帮助,最后谢谢我的导师（真的很牛），他也很耐心的教我，特别感谢名字的话就不说了，不然以后有人烦他去了

谢谢大家我真的很珍惜这次机会，谢谢开源之夏，谢谢OpenTiny社区，谢谢导师，那我的这次开源之旅就结束，但是我相信只是暂时，我以后还会继续投身到开源里面，也希望可以帮助更多的人

关于OpenTiny

欢迎加入 OpenTiny 开源社区。添加微信小助手：opentiny-official 一起参与交流前端技术～

OpenTiny 官网：https://opentiny.design
OpenTiny 代码仓库：https://github.com/opentiny
TinyPro 源码：https://github.com/opentiny/tiny-pro
欢迎进入代码仓库 Star🌟TinyEngine、TinyVue、TinyNG、TinyCLI、TinyEditor~
如果你也想要共建，可以进入代码仓库，找到 good first issue标签，一起参与开源贡献~


0x00 项目背景与前提

0.1 项目场景
最近接了个钓鱼演练的活，整的焦头烂额，连续爆肝两天，我的主要目标是通过社会工程学手段测试企业员工的安全意识和邮件网关的防护能力。客户环境如下：
● 目标规模: 5000+ 员工，多个事业部

● 邮件系统: coremail

● 防护措施: 未知

0.2 初始工具选择
作为穷人，公司也并没有提供商业工具，我选择了 Gophish 作为基础钓鱼平台，原因如下：
●✅ 开源且成熟稳定
●✅ 支持完整的项目管理
●✅ 内置邮件追踪和统计
●✅ Go语言开发，便于二次开发

0.3 面临的核心挑战
然而，直接使用原版Gophish进行测试时，我遇到了100%的拦截率：
​

测试结果（Day 1）:
├─ 发送邮件: 50 封
├─ 成功投递: 0 封
├─ 被拦截: 50 封
└─ 拦截原因: "Suspected phishing activity detected"

0x01 发件基础设施搭建：从失败到可信域绕过
在正式进行钓鱼测试前，我首先需要解决邮件投递问题。

1.1 第一次尝试：Postfix SMTP（失败）

初始方案
最开始，我尝试使用自建Postfix邮件服务器直接发送钓鱼邮件：（至于为什么不用ewomail，网上都推荐的这个，因为不是centos，没办法跑，直接找了最简单的进行测试了。）
​

sudo apt-get install postfix

myhostname = mail.phishing-domain.com
mydomain = phishing-domain.com
myorigin = $mydomain

测试结果
QQ邮箱 通过。
163邮箱 通过。
189邮箱 失败，550。
客户给的测试邮箱 失败 550。



日志输出：

猜测失败原因：

问题

189网关判定
IP信誉低

垃圾邮件发送源
无SPF记录

伪造发件人
无DKIM签名

身份不可信
域名年龄新

钓鱼域名特征
反向DNS缺失

非正规邮件服务器


投递率：0% （全部被189网关在SMTP握手阶段拒绝）

1.2 第二次尝试：Zoho企业邮箱（成功）

解决思路
既然自建服务器信誉不足，我决定借助成熟的企业邮箱服务：
● 选择Zoho Mail：免费企业邮箱，支持自定义域名

● 域名准备：购买类似域名，没要求就以便宜的为主了

● 完整配置：SPF、DKIM、DMARC三件套

Zoho邮箱配置过程
步骤1：注册Zoho企业邮箱

步骤2：配置DNS记录

步骤3：验证配置

步骤4：创建发件账户

测试结果（可信域绕过成功）
第一轮测试：纯文本邮件

结果：

重大突破：通过Zoho企业邮箱 + SPF/DKIM/DMARC配置，189是可以收到邮件的。
正当我以为一切都结束的时候，给客户发，得到的回复依然是收不到。
‍

1.3 第三次尝试：钓鱼模板发送（再次失败）
虽然可信域问题解决了，但当我发送真实钓鱼内容时，又遇到了新的拦截：

测试邮件（含钓鱼内容）

测试结果



这就很有意思了，众所周知大企业一般布有企业级邮件网关，那么他邮件网关到底是拦截的什么，是什么策略？这些我们都不得而知，只有一点点fuzz了。
猜测失败原因：

检测层
结果
详情
✅ SPF验证
PASS
Zoho授权发送
✅ DKIM验证
PASS
邮件签名有效
✅ 域名信誉
PASS
Zoho企业邮箱可信
❌ 内容检测
FAIL
触发关键词过滤


猜测被拦截的关键词：

1.4 阶段性总结
经过几轮尝试，我得出以下结论：

已解决的问题
1 可信域检测 → 通过Zoho企业邮箱 + SPF/DKIM/DMARC配置绕过

2 IP信誉问题 → 使用Zoho的可信IP池

3 SMTP握手 → 正常完成，不会在连接阶段被拒绝

仍存在的问题
1 内容关键词检测 → 189网关对邮件内容进行深度扫描

2 钓鱼模式识别 → "点击链接+验证信息"等模式被识别

3 URL路径检测 → "verify"、"login"等路径触发拦截

下一步策略
既然可信域问题已解决，但内容仍被拦截，我需要：
1对Gophish进行二次开发，去除工具指纹。
2继续FUZZ邮件内容找到网关盲区。
这也是本文后续章节的核心内容。

0x02 二次开发阶段：去指纹化改造

2.1 指纹分析
通过我能够发送成功的邮箱获取到未改造前的eml，我识别出以下Gophish特征：

邮件头特征



‍

URL特征



服务端特征

2.2 改造策略
感觉特征有点多，基于分析结果，决定先把Gophish本身的特征改一下。

改造清单

模块
原始特征
改造方案
文件位置
邮件头
X-Gophish-*
完全移除或伪造成业务头
models/email_request.go
Mailer
X-Mailer: gophish
伪造成常见邮件客户端
models/email_request.go
服务端
Server: gophish
移除或伪装成Nginx
config/config.go
追踪路由
/track
→ /resource/image/pixel.png
controllers/route.go
上报路由
/report
→ /api/v1/status
controllers/route.go
静态资源
gophish.css
→ app.css
static/, templates/
404页面
Gophish默认页面
伪造Nginx 404
controllers/phish.go


核心代码改造
1. 移除服务端标识

2. 邮件头特征处理
对比原版Gophish和修改后的版本：



关键改动：
1 不设置 X-Mailer: gophish

2 不设置 X-Gophish-Contact

3 不设置 X-Gophish-Signature

4 添加 X-Priority: 1（提升邮件优先级）

5 添加 Importance: High（标记重要邮件）会在邮箱里面自主设置为红色叹号

6 保留 用户自定义邮件头功能（SMTP配置中可添加）

说明：
●原版Gophish出于"透明度"考虑，会主动添加X-Gophish-*头标识自己
●我的改进方案是完全不设置这些头，让邮件看起来像普通业务邮件
● 通过添加X-Priority和Importance头，模仿Outlook等客户端发送的重要邮件

3. 混淆追踪路由

4. 伪造Nginx 404页面

5. 修改参数名称

6. 动态QR码功能开发（借鉴EvilGophish）
这是一个新增的需求。
在测试过程中，猜测如果超链接被拦截，那就是检测的明文URL，于是借鉴了EvilGophish项目，实现了动态QR码生成和CID嵌入功能。

与原版Gophish的区别
原版Gophish的CID支持（已有功能）：

使用方式：
1在模板编辑器中上传静态图片（如logo.png）
2 在HTML中使用<img src="cid:logo.png">

3 限制：所有收件人看到相同的图片（问题就来了，没有办法追踪谁点击了）

改进（基于EvilGophish）：

核心区别：

特性
原版Gophish
EvilGophish改进
CID嵌入
支持
支持
图片类型
静态附件
动态生成QR码
个性化
所有人相同
每人专属（含个人ID）
URL跟踪
无法追踪
QR码包含rid参数


为什么需要动态QR码？
根据EvilGophish和相关研究，QR码在钓鱼中具有独特优势：
1 隐藏明文URL - URL被编码为二维码图片，邮件网关的URL检测和沙箱分析无法直接提取

2 提升可信度 - 企业邮件（年终奖、考勤）常用二维码，符合用户认知

3 绕过桌面安全 - 用户用手机扫描，手机浏览器安全警告较弱

4 绕过过滤器 - QR码是图片，不包含文本链接

实现过程（参考EvilGophish）

邮件中使用

生成的邮件结构：

CID嵌入 vs 远程加载对比
方案1：CID内嵌（我们采用）

方案2：远程加载（不推荐）



对比分析

特性
CID内嵌
远程加载
优势方
避免"显示图片"提示
✅ 直接显示
❌ 需用户点击
CID
隐藏服务器地址
✅ 无URL
❌ 暴露域名
CID
加载速度
✅ 即时显示
❌ 依赖网络
CID
提升可信度
✅ 图片完整
❌ 可能显示占位符
CID
邮件网关检测
✅ 仅检测Base64
❌ 检测外部URL
CID
追踪能力
❌ 无法追踪打开
✅ 可追踪加载
远程
邮件大小
❌ 较大（含图片）
✅ 较小
远程


关键优势解析
1避免邮件客户端安全机制

1隐藏钓鱼服务器地址

1提升邮件真实性
○ 远程图片：收件人需要主动点击"显示图片"，增加怀疑

○ CID图片：邮件打开即完整显示，符合正常企业邮件习惯。

‍
‍

0x03 困境：FUZZ机制

3.1 新的拦截机制
其实做到上面的的工作，大部分情况下可以操作了，但是我仍然处于被拦截的情况，因为是黑盒测试，我无法收到邮件的反馈，只能按语义检测进行尝试绕过了：

邮件网关的语义检测机制

拦截案例分析
我被拦截的邮件样本：

拦截原因分析：
1 具有引导性词汇: "重要"、"升级"、"验证"

2 行动引导: "请点击"

3 案例模板: "验证账户信息"是经典钓鱼话术

3.2 心路历程
此时我陷入了困境：如果单纯的是关键字检测，这个模板是客户定的，一时半会重改不太现实，等于说是模板改不了的情况下要如何实现发送。
我不知道邮件网关的确切检测规则，纯粹靠猜测和试错。
拦截原因猜测：

检测层
触发点
详情
邮件头检测
通过
X-Mailer、Subject编码正常
纯文本检测
通过
text/plain部分无敏感词
HTML内容检测
拦截
检测到明文"年终奖金"、"身份证"、"银行卡"
URL检测
拦截
路径包含"verify"、"status"
行为模式
拦截
"点击链接"+"验证信息"模式


啥也不清楚，就此开蒙。

3.3 单变量Fuzz：定位拦截触发点
在知道邮件被拦截后，我需要精确定位到底是什么触发了189网关的拦截。

单变量测试方法
基于smtp_block_tester.py脚本：

测试结果分析;

关键发现
通过单变量Fuzz测试，定位了189网关的拦截规则：

测试变量
是否拦截
结论
纯文本
否
基线通过
普通超链接
否
链接本身不触发拦截
"年终奖"
是
敏感词触发点1
"身份证/银行卡"
是
敏感词触发点2
主题含"年终奖"
是
主题也会被检测
"请点击"
否
单独不触发


核心结论：
1关键词检测优先级最高：无论在主题还是正文，"年终奖"、"身份证"、"银行卡"都会立即触发拦截
2超链接本身安全：普通HTTP链接不会触发拦截
3组合拦截机制：虽然"请点击"单独不触发，但"请点击链接+敏感词"会提升拦截优先级

下一步策略
既然定位到了明文关键词检测是核心拦截点，接下来可以做的是：
1保留整体邮件结构（Multipart、链接等）
2重点混淆敏感关键词（"年终奖"、"身份证"、"银行卡"）
3测试HTML混淆技术能否绕过189网关的关键词检测
这就引出了我的核心绕过方案：HTML混淆Fuzz 。

0x04 突破：基于HTML混淆的Fuzz绕过

4.1 困境分析与新思路
在语义层面被拦截后，我陷入了思考：
邮件网关如果检测的是明文内容，有可能还会对HTML进行检测，因为Gophish就支持HTML布局。
"既然语义敏感词无法避免，能否通过HTML混淆让网关看不懂？"

4.2 HTML混淆Fuzz框架
这是一套渐进式HTML混淆测试系统：

核心思路

HTML混淆武器库
基于WAF绕过经验，准备了以下混淆技术：

混淆技术
原理
示例
HTML实体编码
将敏感字符转为Unicode实体
年终奖 → &#x5E74;&#x7EC8;&#x5956;
CSS文字反转
用CSS reverse文字顺序
年终奖 → <span class="r">奖终年</span>
HTML注释截断
在敏感词中插入注释
验证 → 验<!-- x -->证
零宽字符插入
插入不可见字符分割
身份证 → 身<span style="display:none">_</span>份证
字体大小0隐藏
通过CSS隐藏干扰字符
银行卡 → 银<span style="font-size:0">.</span>行卡


自动化Fuzz测试工具

4.3 Fuzz测试实战过程

第一轮：单一混淆技术测试
针对"年终奖"关键词，测试各种混淆：

结论：所有混淆技术都有效！邮件网关只检测明文，不解析HTML混淆。

第二轮：组合混淆测试
测试实际钓鱼场景的完整邮件：

测试结果：

组合方式
投递结果
说明
全部明文
✗ 拦截
基线
仅CSS反转
✓ 成功
单一混淆有效
仅HTML实体
✓ 成功
单一混淆有效
混合混淆
✓ 成功
多种混淆叠加最佳
混合+注释
✓ 成功
可读性和绕过兼顾


第三轮：Multipart/Alternative测试
结论：添加纯文本版本可显著提升投递率！

测试对比：

邮件格式
投递率
说明
纯HTML（混淆）
68%
部分网关仍拦截
HTML+TXT（TXT安全）
89%
显著提升！
HTML+TXT（两者都混淆）
72%
TXT也会被检测


 最佳实践：纯文本使用安全词汇，HTML中进行混淆

第四轮：CID图片嵌入测试
为了进一步提升可信度，我测试了CID图片（邮件内嵌图片）：

测试结果：
●CID图片不会被URL检测拦截
●可以隐藏真实钓鱼链接
●提升邮件可信度（看起来像官方邮件）

4.4 Fuzz成果总结
经过几天的持续测试，得出以下结论：

有效的HTML混淆技术

黄金组合方案

最终测试数据对比

0x05 最终解决方案：Gophish集成与模板优化
基于Fuzz测试的发现，我将混淆技术集成到Gophish平台中。

5.1 Gophish邮件生成改造

核心改动
我在gophishV4Modified/models/email_request.go中实现了Multipart/Alternative支持：

改造要点：
1 引入html2text库：自动将HTML转换为纯文本

2 Multipart/Alternative结构：

○ 先设置text/plain（安全内容）

○ 再添加text/html（混淆内容）

1 业务邮件头：添加X-Priority、Importance提升信任度

5.2 钓鱼邮件模板设计
基于Fuzz测试结果，我创建了新的钓鱼模板：

钓鱼模板.html（真实版本）

对应的纯文本版本（可选）
如果手动指定Text模板，使用安全词汇：

策略：纯文本完全干净，邮件网关检测纯文本时无异常；用户打开邮件时默认显示HTML（包含混淆的敏感内容）。

5.3 动态模板生成器（可选）
为了避免重复模板被机器学习识别，可以实现变体生成：

5.4 URL路由混淆增强
配合HTML混淆，我也优化了追踪链接：

5.5 最终方案架构

0x06 最终测试与成果

6.1 全量测试
应用所有绕过技术后，我189的测试邮箱终于进信了。



同时以此策略改了以下邮件标题换为行政通知不出现年终奖等内容，防止邮件title检测，发送了一份测试邮件到客户的企业邮箱：



第二天就收到了好消息：



‍
我擦累终于完事了。
提供一个发送成功的EML信息以供fuzz。

AI分析如下：





开始大批量的进行安全测试：



‍



0x07 后记
这次从0到1的绕过之旅，历时4天，最终完成这个需求。
随着AI技术的发展，邮件网关的检测能力会越来越强。下一步的研究方向可能包括：
●利用合法平台（如Google Docs、OneDrive）进行跳转
●转向SMS钓鱼（Smishing）等其他渠道
安全对抗是一场永无止境的竞赛。保持学习，持续创新。

附录

A. Gophish改造Checklist

B. 参考资源

Gophish官方资源
●Gophish官方文档
●Gophish GitHub仓库

Gophish二次开发与改造
● Sprocket Security - Customizing Gophish - 详细介绍Gophish去指纹化改造方法

● EvilGoPhish - Gophish与Evilginx3集成方案，支持MFA绕过

● sneaky_gophish - Docker化的隐蔽Gophish部署方案

● FreeBuf - Gophish钓鱼平台二次开发 - 二维码替换功能实现

● CSDN - 基于Gophish的钓鱼渗透测试平台 - 平台化二次开发思路

Evilginx与MFA绕过
● Evilginx2 官方GitHub - 高级中间人钓鱼框架

● Evilginx3 文档 - 最新版本使用指南

● outpost24 - Evilginx与Gophish组合使用 - 红队钓鱼基础设施搭建

邮件网关绕过技术
●邮件头安全最佳实践 (RFC 5322)
●Fuzzing技术概述 (OWASP)
●社会工程学防御指南 (SANS)

红队钓鱼实战
● Red Team Cafe - Phishing Infrastructure - 红队钓鱼基础设施搭建

● HackenProof - Advanced Phishing Techniques - 高级钓鱼技术

● 腾讯安全 - 钓鱼演练工具Gophish部署 - 企业钓鱼演练实践

END
‍
相关代码已开源至GitHub：https://github.com/25smoking/GophisModified

​

现在的 AI 客户端简直是百花齐放，讨论相对较多的应该就属 CherryStudio 和 OpenWebUI 了

先聊 CherryStudio

  • 优点：UI 设计确实审美在线，比 ChatBox 精致不少，而且多服务商、多模型的接入和切换非常方便，主打一个方便快捷，打开软件就能用。
  • 硬伤：对话历史的堆积，个人目前体验变得非常卡；最可惜的是缺乏原生多端同步。

再说 OpenWebUI

  • 优点：走的是 Web 架构路线，界面复刻了 ChatGPT 的极简风格，上手几乎是零门槛。函数调用、知识库，还有高度可定制化的设置非常优秀，比如模型参数、权限、检索策略这类设置，很多客户端只是给个开关意思一下，它是给你一整套可控面板，当然还有我最需要的多端同步

  • 缺点：模型太多的时候就很不方便管理，而且不支持 Gemini 接口的原生接入。高度可自定义化也意味着默认体验未必最佳 —— 你得自己调，调好了很爽，没调好就容易变成功能太多太杂，懒得去动的状态。

但我想要是能把二者相结合岂不是绝杀？能的佬友，能的！

① 对话高级参数完整汉化 + info 黑框重做：能直接看到更明确的用量和消费

还在纠结 CherryStudio 和 OpenWebUI？我全都要！2
还在纠结 CherryStudio 和 OpenWebUI？我全都要！4

② 自定义上下文条数：可以设置发送给模型的历史消息上下文的最大条数，有效节省 Token

还在纠结 CherryStudio 和 OpenWebUI？我全都要！3


还在纠结 CherryStudio 和 OpenWebUI？我全都要！5

③ 外部连接显示优化：作为一只屯屯鼠，公益站 / API 站一多，设置界面简直就是灾难。改成双列显示，管理效率直接拉满

还在纠结 CherryStudio 和 OpenWebUI？我全都要！6

④ Gemini 原生端口支持：不依赖 OpenAI 兼容层，直接走 Gemini 原生接口，可同步模型列表， thinking_budget 这类特有参数也能上，同时支持流式传输图片

还在纠结 CherryStudio 和 OpenWebUI？我全都要！7

⑤ 外部链接可备注名称 + 可点击名称直达 URL 设置：
本屯屯鼠最大的噩梦，看着一堆 URL 无从下手，现在能直接备注，方便区分，还能点名字直接跳转到设置，不用怕点错小齿轮，适合链接多的佬

还在纠结 CherryStudio 和 OpenWebUI？我全都要！8

⑥ 模型界面缓存逻辑优化：当模型列表过多时，不用再转圈圈等待

⑦ 自动按模型名匹配 Logo：不用再手动每个模型点进去添加图标了，增加了常见的 LLM 品牌 Logo 自动匹配（GPT/Claude/Gemini/Qwen…），对齐 CherryStudio

还在纠结 CherryStudio 和 OpenWebUI？我全都要！9


还在纠结 CherryStudio 和 OpenWebUI？我全都要！10

⑧ 首页模型切换处增加直达模型设置按钮：选模型的地方增加设置跳转，方便快速管理模型

还在纠结 CherryStudio 和 OpenWebUI？我全都要！11

⑨ 模型计费 + 用量统计前端同步 info 黑框：支持免费 / 按次 / 按量三种模式，实时计算对话成本

还在纠结 CherryStudio 和 OpenWebUI？我全都要！12

⑩ 推理强度 / Reasoning Effort 支持下拉 + 自定义输入

还在纠结 CherryStudio 和 OpenWebUI？我全都要！13

其余设置优化：(关于联网搜索不准确的解决方案)

优化 OpenWebUI 联网搜索功能【点击展开】

1、先按照图片设置 Documents 文档和联网搜索，重排模型根据自己的模型配置：

还在纠结 CherryStudio 和 OpenWebUI？我全都要！14


还在纠结 CherryStudio 和 OpenWebUI？我全都要！15

2、复制这段提示词到 Documents 文档设置中的 RAG 提示词模板中，再次试试联网搜索，会有惊喜

### Task:  
Respond to the user query using the provided context, incorporating inline citations in the format [id] **only when the <source> tag includes an explicit id attribute** (e.g., <source id="1">).  
  
### Guidelines:  
- If you don't know the answer, clearly state that.  
- If uncertain, ask the user for clarification.  
- Respond to the user query in Chinese.  
- If the context is unreadable or of poor quality, inform the user and provide the best possible answer.  
- If the answer isn't present in the context but you possess the knowledge, explain this to the user and provide the answer using your own understanding.  
- Only include inline citations using [id] (e.g., [1], [2]) when the <source> tag includes an id attribute. 
- Do not cite if the <source> tag does not contain an id attribute.  
- Do not use XML tags in your response.  
- Ensure citations are concise and directly related to the information provided.  
- Current Date: {{CURRENT_DATE}}. If there is conflicting information, prioritize the latest events based on the timeline.  

### Rules for using web sources (especially time‑sensitive questions)
- For time-sensitive queries, prioritize webpages published within the **last 3–5 days**.
- If old data conflicts with new data, strictly prioritize the **latest publication time**.
- If multiple sources conflict, prioritize sources that are both **most recent AND from authoritative media/official institutions**.
- If sources disagree on the same fact, explicitly point out the discrepancy in your answer and justify which source you consider most reliable.
- Verify key facts against other sources to check for contradictions.

### Example of Citation:  
If the user asks about a specific topic and the information is found in a source with a provided id attribute, the response should include the citation like in the following example:  
* "According to the study, the proposed method increases efficiency by 20% [1]."  
  
### Output:  
Provide a clear and direct response to the user's query, including inline citations in the format [id] only when the <source> tag with id attribute is present in the context.  
  
<context>  
{{CONTEXT}}  
</context>  
  
<user_query>  
{{QUERY}}  
</user_query>

Docker 一键部署命令【点击展开】 
docker run -d \
  --name open-webui \ --restart always \
  -p 3000:8080 \
  -v open-webui:/app/backend/data \
  ghcr.io/ztx888/openwebui:latest
  • 浏览器访问：http://你的服务器IP:3000
  • 数据持久化在 Docker 卷：open-webui（用于重启或者更新的时候不丢配置和对话）

如果你本机没有 Docker 卷习惯，也可以改成本地目录挂载：

mkdir -p ./open-webui-data

docker run -d \
  --name open-webui \
  --restart always \
  -p 3000:8080 \
  -v $(pwd)/open-webui-data:/app/backend/data \
  ghcr.io/ztx888/openwebui:latest

最后必须说一句

非常感谢各位公益站站长的付出和维护，真的帮各位佬省了太多折腾和成本。提供节点、反代、还是日常兜底运维，都很不容易，向各位站长致敬。

遇到问题欢迎反馈

我会持续迭代同步更新官方上游，如果你装了之后遇到问题、或者有更想要的功能点，欢迎来反馈

📌 转载信息
原作者：
Leon666
转载时间：
2026/1/14 10:40:43

总有人说 MoonTV 卡，其实我自己也觉得挺卡的，归根结底就是因为原版设计的存储结构有缺陷。

一个号有 80 条播放记录响应 10 秒才返回数据，能不慢吗，还有一些其他的问题就不多说了
现在优化到基本上返回都在 1s 以内，体验可谓是大幅提高，没更新的都建议更新一下，速度变快超多。

还加了不少功能，详情可以看 changelog

最近应该会暂时停更了，被某个二开抄袭，我上啥新功能他就抄啥

📌 转载信息
转载时间：
2026/1/1 15:31:19