🚀 jd-cookie-helper - 京东cookie辅助工具

🛠️ 工具简介

jd-cookie-helper 是一款基于Electron开发的京东多账号 Cookie 管理工具，专为青龙面板自动化任务玩家量身打造。告别传统浏览器反复登录、手动抓取Cookie的繁琐操作，一键实现全自动登录+Cookie提取！

🌟 核心功能亮点

1️⃣ ​批量管理账号

• 集中保存所有JD账号，告别记事本散装记录
• 支持「全部打开」秒启所有账号登录页
  

2️⃣ ​智能填充提速

• 自动填写手机号，跳过手动输入
• 自动触发验证码请求（需完成滑动验证码，目前滑动验证码通过率较低，需要一定技巧，应该是风控）
  

3️⃣ ​青龙专属适配

• 登录成功即弹窗，点击复制直接生成 pt_key=xxx;pt_pin=xxx;
• 无缝对接青龙脚本，告别格式拼接错误

🚀 极简操作教程

1. 打开应用 → 添加账号
2. 点击「全部打开」→ 自动弹出一键填号页面
3. 手动完成滑动验证码（注：滑动成功率较低，文末有增加成功率方法）+ 短信验证码填写
4. 登录成功 → 点击「确定」即可将 cookie 粘贴到青龙面板

🔗 项目地址

GitHub: https://github.com/erguotou520/jd-cookie-helper

📚 FAQ

Q1. 滑动验证码如何提高通过率？

A: 速度不要太快，滑动时不要保持一条直线，模拟手指滑动时的弧度感。

Q2. Mac 运行时提示已损坏？

A: 在 shell 中执行下面的命令再重新打开

1

xattr -r -d com.apple.quarantine /Applications/jd-cookie-helper.app

Q3. 工具安全吗？会泄露账号吗？

A: 数据完全本地存储，无云端同步，代码已开源，代码地址 https://github.com/erguotou520/jd-cookie-helper

⬇️ 立即下载体验

目前只提供了 Github 的 Release 地址，如果有需要可以留言，我再提供其他下载渠道。

https://github.com/erguotou520/jd-cookie-helper/releases

🚀 iGit - 智能 Git 工作流助手

💡 项目简介

在日常开发中，Git 工作流是每个开发者必不可少的一部分。然而，标准化提交信息、执行代码检查、确保代码质量等工作往往需要耗费大量的时间和精力。iGit 正是为解决这些问题而生的智能 Git 工作流助手，它能够帮助你实现更智能、更高效的 Git 工作流程。

✨ 核心特性

• 🤖 AI 驱动的提交信息 - 自动生成符合约定式提交规范的提交信息，让你的提交历史更清晰、更专业
• 🎯 智能 Git Hooks - 提供一系列开箱即用的 Git Hooks，帮助你规范代码提交流程
• 🎈 简单易用 - 通过简单的命令行工具，轻松集成到你的项目中
• ⚙️ 高度可配置 - 提供灵活的配置选项，满足不同项目的需求

🛠️ 技术栈

• Node.js
• OpenAI API
• Git Hooks
• YAML 配置

📝 安装与使用

1. 安装依赖

1
2
3
4
5
6
7
8

# 使用 npm
npm install -D @doremijs/igit-cli

# 使用 yarn
yarn add -D @doremijs/igit-cli

# 使用 pnpm
pnpm add -D @doremijs/igit-cli

🚀 fe-conf - 配置生成器

前端喜欢造轮子，也喜欢搞各种工程化，项目中经常配置了各种工程化工具，而这些工具要么是xxx-cli初始化生成，要么自己手动配置，每次针对项目可能还要做一些配置调整，而且看着package.json里一堆依赖又很碍眼，而fe-config就是用来解决这个问题的。

fe-conf由2个项目共同组成（后续可以合并？），一个配置生成器config-generator，一个默认配置好的配置集合doremi-config。2者配合使用就可以完成项目工程化的配置。当然fe-conf生成的是默认配置，你也可以按照自己的需求进行调整。

🛠️ OpenAPI Generator - API 客户端生成

💡 项目背景

在现代前端开发中，与后端 API 的交互是不可或缺的。然而，手动编写 API 调用客户端不仅耗时，还容易引入类型和调用错误。@doremijs/o2t 正是为了解决这一痛点而生的 OpenAPI 客户端生成工具（简称o2t）。

✨ 核心特性

• 🚀 全自动生成类型安全的 TypeScript API 客户端
• 🎯 简单配置，一键生成
• 📦 灵活的拦截器和错误处理机制
• 🔒 支持 OpenAPI/Swagger 规范（v2 和 v3）

🛠️ 技术栈

• TypeScript
• Fetch API
• OpenAPI/Swagger 规范

🚀 图片压缩工具 - 本地的极速图片压缩工具

在前端开发过程中，图片资源的优化一直是一个重要的环节。过大的图片文件会影响网站的加载速度和用户体验，而手动压缩图片又比较繁琐。市面上虽然有很多图片压缩工具，但大多数要么是在线服务需要上传下载，要么是收费软件。为了解决这个问题，我开发了一个简单易用的本地图片压缩工具。

这是一个使用 Electron 和 Sharp 开发的图片压缩应用程序，专为前端开发者/UI设计师使用，用于批量压缩图片。它模仿了 ImageOptim 的使用体验，但增加了一些个性化的功能。

原本我是打算使用 Tauri 开发的，但是在处理 libvips 和 pngquant 的动态、静态编译时遇到了一些技术难题，所以最终选择了更成熟的 Electron 框架。

🖼️ 预览

🚀 文汇 - 文档管理平台

在企业应用开发过程中，我们经常需要提供各种合规文档，比如隐私政策、用户协议、免责声明等，这些文档通常需要定期更新，以确保它们符合最新的法律法规和公司政策。当我们在小程序中集成这些文档时，通常需要手动更新，非常麻烦，而且需要重新审核，同时网页端应用可能也要展示这些文档，所以一个可以同时服务多端的文档管理工具就比较重要。这也是我创建文汇(wenhui)项目的初衷。

项目的整体框架我是直接从之前的sync-gitea-server项目中继续迭代过来的，所以在开发和配置上会有很多相似的地方。

后来业务上需要使用本服务多项目较少，所以没有继续迭代。未来可扩展的一些方向有文档复制、文档搜索、文档统计等等，也可以做成商业化产品。

文汇是一个文档管理平台，旨在帮助用户更高效地管理和利用文档资源。它提供了一个集中存储、组织和检索文档的系统，同时支持文档的协作和共享。

我为项目创建的 slogan 是：

「汇聚文档，赋能应用」 (Where docs meet apps)

🚀 sync-gitea-server - 代码仓库同步工具

我们开发时的代码仓库一般都放在阿里云效上，刚开始我们尝试使用云效自带的流水线来实践CI/CD流程，但是云效有很多限制，甚至绑定了阿里云的体系，导致很多场景没法实现自动化，于是我们将CI/CD流程迁移到内网实现。我们对比了一些开源方案，最终选择Gitea作为代码同步仓库，并使用Gitea自带的Actions来实现CI/CD流程。Gitea的几个特点正好符合我们的需求：

• 轻量级，资源消耗少，部署简单
• 支持兼容Github Actions的语法来实施CI/CD流程，可以直接服用现有的大量Actions能力
• 支持LDAP认证，可以直接使用内网的用户体系

唯一的问题是无法实现自动、实时地从云效同步代码到Gitea，于是我开发了sync-gitea-server项目，用于实现自动、实时地从云效同步代码到Gitea。项目的整体框架我是直接从之前的fake-sms项目中复制过来的，所以代码结构上会有很多相似的地方。

sync-gitea-server是一个用于同步代码仓库的 webhook 服务器。当上游代码仓库（如云效）发生变更时，它会向此服务器发送webhook 事件，服务器随后调用Gitea API 来同步这些变更。

通过这个服务器，我们可以实现代码仓库的自动、实时同步，无需人工干预。目前该项目已经在我们内网运行，新项目都已经接入，非常稳定。

🖼️ 预览

🚀 fake-sms - 模拟短信服务器

这是一个搁置了的项目，原本是想要在多项目中使用，但是后来没有项目可应用，就暂时搁置了，但是我觉得它还是很有价值的。项目整体流程没有得到完全的测试，可供参考，请不要在生产环境使用。

fake-sms是一个用于测试基于短信的应用程序的模拟短信服务器，在项目开发时使用它来代替真实的短信发送，可以减少企业在测试环境中的成本。

默认情况下，fake-sms 与 Casdoor go-sms-sender 兼容。

🌐 在线体验: https://fake-sms.erguotou.me （家中服务器，暂时关闭）

🖼️ 预览

🚀 rust-http-server - 极简HTTP服务器

多年没有更新博客了，不过工作期间倒是在做项目中提炼了一些项目和工具，现在开始整理下这些项目并记录下。

做前端的或许都知道http-server或者serve模块，它们都是用来快速启动一个http服务，方便本地开发调试和提供简单的文件服务。我也想复现一个，并学习下Rust语言，于是就开始了入坑之旅。

为什么用Rust再造一个HTTP服务器？

🌟 项目背景：现有工具的痛点

作为前端开发者，你是否厌倦了这些场景？

• 每个项目都需要配置一次nginx
• 调试nginx配置时频繁修改.conf文件
• 启用压缩可能需要安装额外的nginx模块
• 代理配置繁琐，SPA 项目每次都需要try_files
• 想快速实现文件上传却要额外搭建服务

这就是我开发Rust HTTP Server的初衷 - 一个专为现代前端部署优化的全能服务器，在单二进制文件中集成了你需要的一切功能！

在工作中使用Fireboom构建镜像后，使用k8s运行容器，发现应用无法访问网络，错误内容是:dial tcp 10.14.228.89:9825: connect: connection refused，导致Fireboom应用无法正常使用。多天排查后发现竟然是Istio的问题。