前言本文章仅为技术研究与学习交流目的，所有功能均基于对游戏协议的分析与探索。研究者应遵守以下原则：
合法合规：禁止用于任何商业用途或游戏作弊行为；
自我责任：产生的任何风险由使用者自行承担；
尊重版权：不得侵犯游戏厂商合法权益。
⚠️ 说明：本文仅用于技术研究与学习，所有操作均在个人实验环境下进行，不涉及生产环境的攻击与绕过。
一、研究背景小游戏作为典型的小程序形态，用户操作背后会与服务端进行频繁的数据交互。例如登录、数据同步、对战逻辑等。这些交互大多通过 HTTPS 接口 或 WebSocket 长连接 完成。研究通信机制的过程，不仅能帮助开发者理解小程序的架构模式，还能为日常的性能调优、安全防护提供启发。
二、研究工具与准备工具：
Reqable：抓包工具，用于分析 HTTPS 请求与响应。
IDEA / VS Code：代码阅读与调试。
反编译工具：对 .wxapkg 包进行反编译，具体步骤可以参考上篇文章 -> 传送门。
准备工作：
抓包工具上安装抓包证书，确保能够捕获 HTTPS 流量。
获取小程序安装包，得到反编译后的源码中的game.js ...
背景近年来，微信小程序以其“无需安装、触手可及”的特性，迅速成为开发者和用户的新宠。它们功能丰富，覆盖了从生活服务到游戏娱乐的方方面面。了解其背后的运行机制和代码结构，有助于开发者更好的学习。
本教程旨在为你揭开微信小程序的“神秘面纱”，一步步教你如何找到小程序的代码包（.wxapkg 文件），并利用现有的工具将其还原成可读的源代码。通过这个过程，你不仅能更好地理解小程序的项目结构和代码逻辑，还能学习到一些小程序开发中的优秀实践。
请注意，本教程所有内容仅用于学习和技术研究，切勿用于任何商业目的或侵犯他人知识产权的行为。
1. 准备工作在开始之前，下载以下工具：
Node.js： 运行反编译脚本的环境
微信PC版： 因为小程序包存放在电脑本地的文件夹中
反编译工具： wxappUnpacker、UnpackMiniApp
2. 找到小程序包（.wxapkg文件）wx电脑版在运行了小程序后，会把代码包（.wxapkg 文件）下载到本地缓存中。在新版的wxPC端中，这些文件位于以下路径：
Windows： C:\Users\用户名\AppData\Roaming\Tencent\xw ...
一、项目背景在对现有TSP系统的Redis进行性能优化时，发现当前分布式系统中，用户登录态通过 Redis 来管理：以键值对形式存储用户的 Token 与用户信息（UserDto），并结合 WebSocket、SSE、Kafka 组件，实现实时通信、消息推送及统一认证（SSO）。
随着业务的发展，发现原有的存储设计存在以下问题：
Key 命名零散、扫描效率低
多处基于通配符 (KEYS STOKENS_{userId}_\*) 的扫描逻辑冗余、性能不佳
WebSocket 端无根据 Token 快速反查用户 ID的逻辑，通过scans进行全量查询
接口逻辑侵入了大量“查旧 Key、删旧 Key”的代码，且可维护性差
随着redis数据量的增多，执行scans需要耗费的时间逐步递增，使用体验差
二、改造思路将 Redis 存储从多 string Key改造为Hash 结构，并在登录、登出、校验、WebSocket 握手、SSE 推送、Kafka 同步等流程中，做出对应改造，彻底简化业务逻辑、提升性能与可维护性
1.Redis Key 结构升级
从 String ...
背景在日常使用 XXL-JOB 的过程中，运维和开发人员经常会遇到这样的需求：
在任务管理页面，希望能够不局限于某个执行器，而是一次性查看所有执行器下的任务情况。
然而，XXL-JOB 默认的实现是必须选择具体的执行器，才能筛选对应的任务。这在一些运维场景下显得不太方便。
如图所示：
因此我在项目中基于xxl-job-2.4.0对xxl-job-admin源码做了一些改造，实现了执行器“全部查询” 的功能，本文就来分享一下具体的改造思路。
一、问题分析XXL-JOB 任务管理页面的查询逻辑中，前端会将选中的 jobGroup（执行器 ID）传到后端，后端再通过 SQL 条件查询对应的任务：
1AND t.job_group = #{jobGroup}
问题是，这样的写法导致必须指定某个执行器，否则查询不到任务。 因此我们需要 在下拉框中增加“全部”选项，并在 SQL 查询时做特殊处理。
二、SQL 改造在 xxl-job-admin 的 JobInfoDao.xml 中，找到任务分页查询方法 pageList，原来的 SQL 条件大概是这样：
123456 ...
一、项目简介XXL‑Job 是一款开源的分布式任务调度框架，提供可视化的任务管理后台、灵活的任务触发策略、失败重试、日志查看等功能。将 XXL‑Job 与 Spring Boot 集成，可以快速在微服务或独立应用中调度定时任务，下面将详细介绍如何一步步完成接入。
二、环境准备
JDK 1.8+
Maven 3.5+
Spring Boot 2.3+
已搭建好的 XXL‑Job Admin（管理后台），可参考XXL部署篇
三、添加依赖在项目根目录下的 pom.xml 添加 xxl-job-core 依赖。以下为完整的 pom.xml 示例：
12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849<?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0" x ...
一、XXL-JOB简介1.1 概述XXL-JOB是一个分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。现已开放源代码并接入多家公司线上产品线，开箱即用。
1.2 参考官方文档地址：www.xuxueli.com/xxl-job/#/
源码地址：
GitHub: github.com/xuxueli/xxl…
环境：
Maven 3.63
Jdk 1.8
Mysql 8.0
1.3 特性
1、简单：支持通过Web页面对任务进行CRUD操作，操作简单，一分钟上手；
2、动态：支持动态修改任务状态、启动/停止任务，以及终止运行中任务，即时生效；
3、调度中心HA（中心式）：调度采用中心式设计，“调度中心”自研调度组件并支持集群部署，可保证调度中心HA；
4、执行器HA（分布式）：任务分布式执行，任务”执行器”支持集群部署，可保证任务执行HA；
5、注册中心: 执行器会周期性自动注册任务, 调度中心将会自动发现注册的任务并触发执行。同时，也支持手动录入执行器地址；
6、弹性扩容缩容：一旦有新执行器机器上线或者下线，下次调度时将会重新 ...
Spring Boot 集成 JavaMailSender实现邮件发送背景邮件发送为项目中的常用功能之一，例如注册成功后需要发送激活邮件，每日报表统计，日志告警监控，数据迁移通知等功能都需要自动发送邮件通知管理员或运维人员处理
具体实现本文将从Spring Boot集成的JavaMailSender来实现邮件发送功能
1、关于JavaMailSenderJavaMailSender是Spring Framework中的一个接口，用于发送电子邮件
它是Spring对JavaMail API的封装，提供了更简单和更方便的方式来发送邮件
JavaMailSender接口定义了一组发送邮件的方法，包括发送简单文本邮件、发送带附件的邮件、发送HTML格式的邮件等
它隐藏了底层JavaMail API的复杂性，使得在Spring应用中发送邮件变得更加容易
JavaMailSender是Spring Framework中用于发送邮件的接口，它简化了邮件发送的过程，提供了更高级的抽象和便利性
2、引入pom依赖1234<dependency> <groupId>org. ...
实现多数据源配置及动态切换背景最近在MySQL大体量数据冷热归档项目的开发过程中，需要从8+数据源的不同业务库（源库、归档库）中，对数据进行迁移操作，动态查询新的源库数据源信息并切换到该数据源所迁移的归档库做相应的查询、插入操作，翻阅了网上很多资料都是简单的对多数据源的整合，并没有涉及到多数据源配置及动态切换的案例
目标
在迁移配置表中，根据source_datasource、target_datasource字段在代码中动态切换对应的数据源信息，将源表数据迁移至归档表数据
详细实现方案一1、pom文件配置项目所需的依赖
123456789101112131415161718192021222324252627282930313233343536373839 <!--web模块依赖--><dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId></ ...
日志系统完善方案背景现状当前业务环境没有统一的日志输出格式，日志文件只能通过HTTP下载，运维人员处理效率低，需要将服务接入日志系统规范及适配性改造等（约150个微服务）；服务增加日志采集（约100个微服务）
目标通过完善日志系统集中收集日志，升级日志链路ID规范，通过打通日志系统链路ID和听云系统链路ID；提高运维效率，缩短问题定位时间由原来的2天降低至1天内
技术栈选择
采集层：Filebeat（轻量级日志采集）
缓冲层：Kafka（高吞吐消息队列，削峰填谷）
处理层：Logstash（日志解析、过滤、富化）
存储层：Elasticsearch（分布式搜索与存储）
展示层：Kibana（可视化分析与仪表盘）
现状与升级后对比总览
系统设计
应用程序日志采集设计
业务集群变更：
在启动命令中加入听云Agent，日志输出时调用链路ID。
统一日志输出模板，升级服务接入日志规范。
日志系统收集全部业务日志。
修改本地存储日期策略，节省服务器磁盘空间。
提供日志收集级别配置，根据实际情况调整日志收集级别。
日志滚动生成：定义并规范日志输出的统一格式，确保日志按一定规则滚动生成。
Fi ...
车辆综合查询报表接口优化背景：
通过日志平台对车辆综合查询接口的响应时间进行分析，发现当前接口的平均响应时间比较长，为了提高用户使用的体验，需要对接口进行优化
目的：
整理用户权限和组织权限之间的区别和涉及到的表信息
基础节点信息的表改造，添加排序字段，优化查询速度
相关接口：
/car/queryMonitorList
/optimize/queryFuelCarList
对接口调用链路分析：
分析发现，主要还是SQL层面的响应时间比较长，所以从SQL进行优化
流程：
首先调用车辆综合报表方法xxQueryFuelCarList
进入查询车辆车次计数xxCarAllCount
遍历车辆节点表xx_Node_CarInFo_Car找到对应节点
对应节点车辆的基础信息表xx_Node_relationship
基础节点SQL
123456789101112131415-- 执行查询，查找根节点及其所有后代节点SELECT id, nameFROM ( SELECT t1.id, t1.pid, ...
