独立开发一个企业级Web系统：斗篷系统（ABcloakPro）的开发实践

作为一名独立开发者，我一直希望通过真实项目探索软件产品从0到1的完整过程。 斗篷系统（ABcloakPro）是一个面向企业级Web应用的访问管理与请求控制系统。 在开发过程中，我经历了从产品定位、架构设计、功能规划、技术选型，到项目文档建设和持续优化的全过程。 本文记录斗篷系统的开发思路，以及一个独立开发者在打造长期维护软件产品过程中的一些实践经验。 一、为什么开始开发斗篷系统 很多软件项目最初都来源于一个简单的问题。 在实际开发Web应用过程中，我发现随着系统规模不断扩大，会逐渐出现一些问题： 1. 系统功能越来越复杂； 2. 不同模块之间耦合越来越严重； 3. 请求管理和数据处理难度增加； 4. 后期维护成本不断提高。 很多项目在初期阶段只关注功能实现，但是当业务持续增长后，架构设计、系统稳定性以及扩展能力会成为新的挑战。 因此，我希望通过开发一个完整项目，探索企业级Web系统从设计到落地的完整过程。 二、斗篷系统是什么 斗篷系统（ABcloakPro）是一套面向企业级Web应用的访问管理与请求控制系统。 项目主要关注： - Web访问管理； - 请求处理； - API接口设计； - 系统架构优化； - 服务通信； - 数据管理； - 系统运行监控。 整个项目目标不是简单完成一个功能，而是探索如何构建一个可以长期演进的软件产品。 三、独立开发过程中遇到的挑战 独立开发和团队开发有很大的不同。 一个人需要同时承担： - 产品规划； - 技术设计； - 编码开发； - 测试维护； - 文档整理； - 项目推广。 最大的挑战不是写代码，而是持续推进项目。 ## 1. 明确产品方向 独立开发最容易遇到的问题是： 不断增加功能，但是没有明确目标。 因此，在开发过程中，需要不断思考： 这个功能是否真正解决用户问题？ 是否值得长期维护？ 是否符合产品方向？ ## 2. 架构设计的重要性 虽然独立项目规模可能不大，但是如果希望长期发展，架构设计依然非常重要。 需要提前考虑： - 模块划分； - 数据结构； - 接口设计； - 部署方式； - 后期扩展。 好的架构可以降低未来重构成本。 四、斗篷系统的技术架构思考 在项目设计过程中，主要关注几个方面： ## 1. 模块化设计 通过拆分不同功能模块，提高系统维护效率。 例如： - 请求处理模块； - 配置管理模块； - API服务模块； - 数据管理模块； - 日志分析模块。 每个模块保持相对独立，方便后续扩展。 ## 2. API接口体系 现代Web系统离不开稳定的接口设计。 接口需要考虑： - 数据格式统一； - 参数校验； - 异常处理； - 安全控制。 通过规范接口，提高系统可维护性。 ## 3. 云环境部署 软件产品不仅需要开发完成，还需要能够稳定运行。 因此需要关注： - 服务器环境； - 自动化部署； - 服务监控； - 故障处理。 五、开发过程中最大的收获 通过持续开发斗篷系统，我最大的收获是： 软件产品不仅仅是代码。 一个完整产品还包括： ## 技术积累 包括： - 架构设计； - 开发经验； - 工程实践。 ## 文档建设 优秀的软件需要： - 使用文档； - 技术文档； - 开发记录。 ## 持续优化 产品不是一次完成，而是在不断迭代过程中成长。 六、为什么坚持做长期项目 很多独立开发项目容易停留在： 完成一个Demo。 但是一个真正的软件产品，需要经历： 想法阶段； 设计阶段； 开发阶段； 测试阶段； 发布阶段； 持续优化阶段。 只有长期维护，项目才会产生真正价值。 七、未来规划 未来会继续完善斗篷系统： 包括： - 功能优化； - 架构升级； - 技术文档完善； - 开发者体验优化； - 社区交流建设。 希望通过持续实践，探索独立开发者打造软件产品的更多可能。 八、总结 独立开发一个企业级Web系统，是一个长期过程。 除了技术能力，还需要产品思维、工程能力以及持续投入。 斗篷系统（ABcloakPro）只是一个开始。 未来会继续围绕Web架构、软件工程、系统设计以及产品开发方向进行探索。 项目地址： GitHub： https://github.com/abcloakpro/Cloak-System 官方网站： https://www.abcloakpro.com

狐蒂云🦊跑路我的摸鱼岛没了！

### 前言🔥 很久没写文章了，没到想我写文章的时候居然是我的网站（摸鱼岛🌟）数据没了！为什么没了！服务商跑路了！！！！没有一点消息，好消息是我的数据备份了！坏消息数据备份的机器被司法硬控了，也相当于没了！！！   尽管是这样！！幸好还有一堆支持我的岛民🐠，支持把我的网站重新开起来，那么即将带来的是我的小网站摸鱼岛！！，文章最后有兑换码可以领取摸鱼岛一周年大礼包！！！ ### 跑路后的处理 🌟 一开始是不知道我的服务器被跑路了，那是一个一切安稳的中午，我美美的更新完我的小网站功能，睡了个午觉，起来手机消息爆了！大家都来问我网站为什么上不去了，我也纳闷因为服务器是我的一个朋友赞助给我的，平常也有这些问题有时候突然挂了我也没太在意，就继续安稳住大家情绪，并通知我朋友进行排查处理看看，一切都是那么的和谐🐔。 快下班的时候我朋友来回我了，他说！爆缸了！聪！服务商跑路了，我想？跑路？没事不是会备份吗，问题不大！ 他说：好消息是备份了！坏消息，备份机器就是跑路那台，被司法硬控了，我 x！雷霆爆缸！！！ 我的 8000 用户数据，全部没了！！！虽然有八千注册，但是活跃的就一两百啦哈哈哈，但是那也是我的岛民幸幸苦苦的数据啊，说没就没了我难受啊，我岛民更难受，每天辛辛苦苦的养宠物，没想到数据没了！！！ 平缓心情后，马上把能找回的数据找回，最后能找回的只有一份赞助榜单数据，后面给摸鱼岛的各位股东都一一找回定制的会员跟称号了，还没联系我的也等待用户联系我进行找回。 重新换了台服务器后，我换了种备份方式🔥，我不把备份数据存在服务器了，从新找了一台腾讯的 COS 来进行备份，我不信腾讯还能跑路！！！！  幸好两天用户就迅速回来两百左右，这两百可是我的摸鱼岛精神股东！！！！  ### 摸鱼岛 3.0 🌸 我写文章已经在一年前了，之前写的摸鱼岛 2.0 没看过的大家可以看一下 <https://juejin.cn/post/7497183377655087158>，项目都是开源的哦，麻烦大家给我点点 star，不要吝啬手中的 star 啊 股东们！！！  ​ > 本项目为开源项目，使用者必须在网站标注作者名称以及指向本项目的链接。如果不想保留署名，必须首先获得授权。不得用于非法用途。 > 在线体验地址🔗[yucoder.cn](https://yucoder.cn) > > 后端地址🌈：[github.com/lhccong/fis…](https://github.com/lhccong/fish-island-backend) > > 前端地址🏖️：[github.com/lhccong/fis…](https://github.com/lhccong/fish-island-frontend) #### 鱼小圈 🌈 这个是模仿朋友圈的样子，来进行编写，谁不想摸鱼时间来分享下自己的生活呢！！  #### 摸鱼宠物 🐳 在摸鱼岛上面能养自己的小宠物！！！谁不想养一只赛博宠物跟自己摸鱼呢～～～   不仅如此！宠物还能进行装备抽奖、装备锻造，妥妥的寻道大千摸鱼版！！！ #### 摸鱼股市 📈 由于最近迷上了股票基金，我就写了一个摸鱼股市，大家能通过自己的积分去投摸鱼股市，摸鱼股市实时监听 大 A 的价格，用摸鱼积分可以进行交易，看看你是不是那个天才交易员！！！  #### 无尽爬塔 🚀 可以用自己养的宠物去进行爬塔！！！狠狠的让宠物给自己打工赚取积分～～  #### 岛主信息🦊 快来摸鱼岛逮捕我吧，逮到我给你发红包、积分！！！  #### 其他端🦈 - 新增了 utools 端，在 utools 搜索摸鱼岛即可快乐摸鱼 - 新增了 app 端，使用了 expo 技术，苹果下载 expo go 来联系我邀请你、安卓进入摸鱼岛，寻找 apk 安装包进行安装哦～ #### 摸鱼岛一周年福利 在用户右上角信息，选择兑换码按钮来进行填入：摸鱼岛一周年快乐 即可领取 2888 积分哦！！！  更多兑换码可以找摸鱼岛的赞助小伙伴们来领取，他们有些特殊兑换码，会有意想不到的奖励哦！ #### ## 最后 ✨ 感谢大家看到最后，我是聪 希望可以跟大家一起学习，如果文章对大家有帮助的话不妨给我的新项目[ 摸鱼岛🐟](https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Flhccong%2Ffish-island-backend) 点个免费的 star 🌟，我的 Github：[github.com/lhccong](https://link.juejin.cn/?target=https%3A%2F%2Fgithub.com%2Flhccong) 如果里面有你感兴趣的项目也可以点个星星⭐和关注🔥，未来我还会持续写新的好玩的小项目。

你可能把网关的事情，写进了容器里

*一次前端容器配置引发的架构思考* 在做前后端分离部署时，我遇到过一个挺有意思的问题。 系统没有报错，页面也能访问，接口也正常，但总感觉配置上哪里“不太对”。 后来回头梳理，发现问题并不在业务代码，也不在代理是否可用，而是在一个很容易被忽略的地方： **我把本该属于网关层的事情，写进了应用容器里。** --- ## 一个看起来很合理的做法 很多人在部署前端项目时，都会在容器内部再放一层 Nginx，用来处理静态资源、缓存和单页应用路由。 这本身完全没问题。 问题出在另一个很常见的动作上： > 给容器内的 Nginx 也写上域名匹配。 比如这样： ```nginx server { listen 80; server_name app.example.com; root /app/dist; index index.html; location / { try_files $uri $uri/ /index.html; } } ``` 第一眼看上去，这样写很正常。 但真正的问题是： **这一层到底应不应该关心域名？** --- ## 先看一眼典型部署结构 在前后端分离项目里，一个常见结构大概是这样： ```text 浏览器 ↓ 网关层（Nginx / OpenResty / Ingress） ↓ 前端容器 ↓ 后端服务 ``` 入口层负责做统一接入，比如： * HTTPS 终止 * 域名接入 * `/api` 转发 * 静态站点转发 * 安全控制 示意配置通常类似这样： ```nginx server { listen 443 ssl; server_name app.example.com; location /api/ { proxy_pass http://backend-service; } location / { proxy_pass http://frontend-service; } } ``` 这时候，**域名匹配的职责其实已经发生在网关层了。** --- ## 问题就出在这里 如果网关已经完成了入口接入，后面的前端容器其实只是一个“内容提供者”： * 提供打包后的静态文件 * 处理前端路由回退 * 做一些基础缓存控制 也就是说，这一层更像是： > “给我什么请求，我就把对应内容吐出去” 而不是： > “我还要再判断一次这个请求是不是属于某个域名” 如果在容器内部继续写： ```nginx server_name app.example.com; ``` 本质上就是在内部链路里，又增加了一次入口层判断。 这不一定马上会出故障，但它会带来一个问题： **系统内部多了一层不必要的耦合。** --- ## 为什么这是个“隐性坑”？ 因为它通常不会立刻炸。 更常见的情况是： * 现在能用 * 访问也正常 * 没有明显报错 * 但配置边界已经开始模糊了 这种问题最麻烦的地方在于： > 它不是“错误配置”，而是“职责放错层了”。 平时可能感知不到，但一旦后面发生这些变化，问题就容易冒出来： * 增加新的访问域名 * 接入 CDN * 调整反向代理链路 * 做多环境部署 * 容器镜像在不同项目复用 这时你会发现，容器内部那层域名配置并没有带来收益，反而成了额外限制。 --- ## 本质上，是职责边界写乱了 这件事说到底，其实就是一句话： > **你把网关该做的事情，放进了容器里。** 如果把职责拆开来看，会更清楚： | 层级 | 更适合负责什么 | | ----- | -------------- | | 网关层 | 域名、入口、协议、路由分发 | | 应用容器层 | 静态资源、应用内容、基础缓存 | | 后端服务层 | 业务逻辑、数据处理、接口响应 | 一旦每层都只做自己该做的事，整个系统会清晰很多。 --- ## 那容器内 Nginx 更合适怎么写？ 前端容器里的配置，通常保留这些就够了： ```nginx server { listen 80; server_name _; root /usr/share/nginx/html; index index.html; location / { try_files $uri $uri/ /index.html; } } ``` 这里的重点不是具体语法，而是这个思路： * 不强调具体域名 * 不承担入口职责 * 专注处理前端资源和路由 如果再稍微补一点生产常见配置，也通常只是这些内容： ```nginx server { listen 80; server_name _; root /usr/share/nginx/html; index index.html; location ~* \.(js|css)$ { expires 7d; } location = /index.html { add_header Cache-Control "no-cache"; } location / { try_files $uri $uri/ /index.html; } } ``` 这些配置的核心仍然是： **让容器服务内容，而不是管理入口。** --- ## 为什么这种写法更合理？ 原因其实很直接。 ### 第一，减少耦合 容器不依赖具体域名后： * 换域名不用改容器配置 * 多环境更容易复用 * 镜像迁移更轻 ### 第二，职责更清晰 网关层只做流量入口的事，容器层只做内容服务的事。 一旦出了问题，也更容易定位。 ### 第三，更符合真实链路 对浏览器来说，访问的是公网域名。 对容器来说，收到的是内部转发过来的请求。 这两者不是同一个阶段，处理逻辑也不应该混在一起。 --- ## 这类问题最值得警惕的地方 很多工程问题，并不是“会不会报错”。 而是： > **配置虽然能跑，但已经悄悄偏离了合理的边界。** 这种偏离一开始往往不明显，甚至还会让人觉得“更严谨了”。 但随着系统变复杂，它就会慢慢变成维护成本。 所以很多时候，技术判断不只是看“能不能工作”，还要看： * 这件事该不该在这一层做 * 这一层的职责是不是被扩张了 * 未来变化时它会不会成为牵制 --- ## 最后总结一句话 > **域名属于入口层，内容属于容器层。** 前端容器里的 Nginx，重点应该是静态资源和路由处理，而不是再承担一遍网关职责。 很多配置不是“错”，只是“放错了地方”。 而工程上的很多坑，恰恰就藏在这种“看起来没问题”的地方。

分享一个自己做的 IP 地理位置查询开放平台：SnapIP，现已启用正式域名

最近把自己做的一个 **IP 地理位置查询接口开放平台** 正式上线了。 **平台首页：** [https://www.kevio.cn/](https://www.kevio.cn/) **API 文档：** [https://www.kevio.cn/docs](https://www.kevio.cn/docs)  之前一直是用服务器 IP 地址对外访问，今天终于把域名也配好了，整体体验会更完整一些。 现在可以直接通过下面的地址访问： 这个项目叫 **SnapIP**，定位很明确： 做一个**开箱即用、可直接接入项目的 IP 归属地查询服务**。  --- ## 为什么会做这个项目？ 原因其实很简单。 一方面，我自己在实际开发里就有这类需求，比如： * 登录日志里展示用户 IP 归属地 * 后台做访问来源分析 * 风控场景里辅助判断异常登录 * 运营侧做地区分布统计 * 一些系统里根据 IP 做基础信息补充 另一方面，我也一直想做一个**真正能上线、能被别人实际使用**的工具型产品，而不是只停留在本地 demo 或者“做完就吃灰”的项目。 所以就把这个平台一步步做出来了，并且真的部署上线，开放给别人使用。 --- ## 目前 SnapIP 能做什么？ 当前平台已经把基础能力跑通，支持通过一个简单的 GET 请求来查询 IP 信息。  目前返回内容包括： * 国家 * 省份 / 城市 * 运营商 * 经纬度 * 时区 * 以及其他共 **18 个字段** 在接入方式上，也尽量做得简单： * **GET 请求即可调用** * **支持 API Key 鉴权** * **支持 JSON / CSV / Text 格式返回** * **注册赠送每日 1000 次免费额度** * 接入成本比较低，几分钟就能跑起来     如果你是开发者，基本看一下文档就能接进去。 --- ## 我理解它适合哪些场景？ 目前我觉得比较适合下面几类使用场景： ### 1）安全与风控 比如： * 异常登录识别 * 高风险地区访问提醒 * 登录审计 * 操作日志归属地补充 ### 2）后台与业务系统 比如： * 用户访问记录展示 * 管理后台查看请求来源 * 工单系统补充 IP 地域信息 * 访客轨迹的基础地域维度分析 ### 3）运营与数据分析 比如： * 用户地域分布统计 * 活跃地区分析 * 推广投放效果观察 * 报表中的地区维度补充 ### 4）开发者工具集成 比如： * 在自己项目中封装成统一接口能力 * 给日志系统、BI 系统、监控系统做数据增强 * 作为开放平台能力给下游业务调用 --- ## 为什么这次我更想认真发出来？ 因为对我来说，**上线域名**这件事，其实意味着这个项目往前走了一步。 它不再只是一个“能跑”的接口，而更像是一个准备认真继续打磨的产品： * 访问入口更正式了 * 对外分享更方便了 * 信任感比直接放服务器 IP 更高 * 后续做 SEO、文档沉淀、品牌化也更容易 某种程度上，这也算是我把这个项目从“自己做着玩”往“可持续运营”方向推进的一次小升级。 --- ## 后面还会继续完善什么？ 接下来我会继续补这些内容： * 接口能力和字段信息继续优化 * 平台文档做得更完整 * 提升调用体验和接入效率 * 根据真实使用反馈补充更有价值的功能 * 继续打磨整体产品感，而不只是一个接口页 我比较希望它不是“能查 IP 就结束了”，而是逐渐变成一个**真正可用、可靠、对开发者友好的开放服务**。 --- ## 现在最希望得到什么反馈？ 目前最需要的，其实不是一句“不错”，而是**真实反馈**。 很欢迎大家从下面这些角度帮我看看： ### 从开发者角度 * 接口设计是否合理？ * 返回字段是否够用？ * 文档是否清晰？ * 接入成本高不高？ ### 从产品角度 * 平台定位是否足够明确？ * 首页表达清不清楚？ * 免费额度和功能层级是否合理？ * 有没有缺失的核心能力？ ### 从运营角度 * 这个产品的目标用户是否清晰？ * 哪些场景更值得重点强调？ * 目前的对外表达有没有说服力？ * 还有哪些更适合推广的方向？ 不管是功能、页面、文案、定价、场景，还是你觉得哪里“不对劲”，都欢迎直接提。 --- ## 体验地址 **SnapIP 平台首页：** [https://www.kevio.cn/](https://www.kevio.cn/) **API 文档：** [https://www.kevio.cn/docs](https://www.kevio.cn/docs) 如果你愿意花几分钟体验一下，或者从开发、产品、运营的角度给点建议，真的非常感谢。 也欢迎直接“拍砖”，真实反馈比客套话更有价值。

# 我做了一个双色球中奖检测网站，因为我实在受不了手动一个个兑奖了

大家好，我是皮蛋侠，好久不见！～ 今天上班不想工作，所以抽空写了这篇文章跟大家吹吹水～ 最近发生了太多太多事情：公司欠薪，找工作，跳槽，ai冲击诸如此类的，埋个坑下次摸鱼的时候再跟大家分享～ --- 每次双色球开奖之后，我都会经历一个非常重复、也非常消耗耐心的流程： 先打开开奖网站，再对着自己手里的票，一组一组去看红球、蓝球有没有中；如果买了几注，或者家里人一起买了几张票，这个过程就会更烦。明明是一件几分钟就该解决的小事，却总让人感觉又碎又累。 后来我想了一下，这件事其实非常适合交给程序来做。 于是，我给自己做了一个小网站：**双色球中奖检测器**。 ------ ## 我为什么会做这个网站 起因其实很简单： **我不想每次开奖后，都去网上手动一组一组对号码。** 尤其是下面这些场景，真的很容易让人想偷懒： - 买了多注号码，要反复核对 - 家里几个人一起买票，要来回切换开奖信息 - 在手机上查兑奖网站，页面体验不一定顺手 - 明明只是想快速知道“中没中”，却被迫做很多重复动作 我想要的其实不是一个“功能特别复杂”的系统，而是一个足够直接的小工具： **打开网页，输入号码或者拍张照，立刻知道结果。** 所以这个网站就这么诞生了。 ------ ## 这个网站能做什么 我给它做的目标很明确：**让查中奖这件事更快、更省事。** 目前它支持这些功能： - 拍照识别双色球票面号码 - 上传图片识别号码 - 手动输入多注号码 - 切换不同期号的开奖结果 - 基于本地数据库快速校验中奖情况 - 支持手机和电脑访问 - 支持局域网使用，家里人也能一起查 - 支持 Docker 部署，自己放在服务器上也很方便 简单来说，它不是一个“资讯网站”，而是一个偏实用的小工具站。 你不需要再自己盯着开奖号码一位一位比对，系统会直接帮你完成识别和校验。 ------ ## 我最在意的，不是花哨，而是省事 做这个网站的时候，我最关心的不是页面有多炫，而是两个字： **省事。** 所以我在设计上一直围绕这个目标： - 尽量少操作 - 尽量适合手机使用 - 尽量不依赖复杂流程 - 尽量让“查中奖”这件事一眼就知道结果 毕竟这个工具本来就是为了解决我的一个日常小烦恼。如果最后做出来还比手动查询更麻烦，那就失去意义了。 ------ ## 为什么我用了本地数据库 很多类似的小工具，都会在用户每次打开页面时去请求远程开奖接口。 但我更希望它能稳定一点，所以这个网站做成了： **优先读取本地 SQLite 数据库。** 这样做的好处很直接： - 查询更快 - 使用更稳定 - 不容易因为第三方接口波动而影响体验 - 更适合自己长期部署 另外，我还把开奖同步逻辑做成了按时间窗口自动拉取，这样平时不会反复去请求外部接口，只有在双色球开奖时段才会自动检查最新数据。 对一个小工具来说，这种方式更轻，也更适合长期运行。 ------ ## 这个网站适合谁 如果你也有下面这些需求，那这个网站可能会刚好适合你： - 你平时会买双色球，想更快核对中奖结果 - 你不喜欢每次都去官网或资讯页慢慢看 - 你家里几个人会一起买票，想有个统一工具 - 你希望在手机上就能直接查 - 你想自己部署一个简单、长期可用的小服务 它不是一个面向大而全场景的平台，更像是一个专门解决“小麻烦”的顺手工具。 但很多时候，真正让人愿意长期使用的，恰恰就是这种工具。 ------ ## 开发这个网站之后，我最大的感受 我越来越觉得，很多个人项目的价值，不一定来自“多大、多新、多复杂”。 有时候，一个项目最好的起点就是： **“这件事太烦了，我想办法把它变简单。”** 这个双色球中奖检测网站就是这样。 它不是为了炫技，也不是为了做成什么宏大产品。 它只是很认真地解决了一个真实存在、而且会反复出现的小问题。 而对我来说，这种项目反而特别有成就感。 因为它真的能用，也真的帮我省时间。 ------ ## 如果你也想试试 如果你和我一样，也觉得每次一个个手动兑奖太麻烦，那这个网站也许能帮你省下不少时间。 你可以把它当成一个轻量、直接、够用的双色球中奖检测工具： - 手机上能用 - 电脑上能用 - 自己本地能跑 - 放到服务器上也能长期用 如果后面我继续迭代，我也会考虑补充更多提升体验的小功能，让它变得更顺手。 ------ ## 仓库地址和体验 仓库地址：https://gitee.com/pidanxia/ssq 体验：https://ssq.pidanxia.ink/ ## 写在最后 这个项目的起因其实非常朴素： **我只是想更轻松地查一次双色球有没有中奖。** 也正因为这个起点足够真实，它才会很自然地被做出来。 如果一个工具，能把一件重复、枯燥、还容易出错的小事变得更轻松一些，那我觉得它就已经有价值了。 这个项目从冒出想法到部署完成，一共只用了 3 个小时。 更有意思的是，整个过程几乎都是由 AI 完成的。 我没有自己写一行代码，更多时候只是不断用自然语言告诉 AI 我想要什么、希望它怎么改、还缺什么功能，然后一点点把这个网站做出来。 现在大家都在说 `vibe coding`。 以前我对这个词没有太强烈的感受，但这段时间确实越来越能体会到它的意思了。 有了 AI 之后，很多过去只是脑子里一闪而过的小想法，真的开始变得可以快速落地。 前阵子有一天晚上，我突然想看电影。 但在网站上在线看总觉得很卡，我就随手想到：能不能先下载到本地再看？ 于是我把这个想法告诉了 AI。 结果大概 15 分钟，它就帮我写出了一个能用的脚本。 附上儿子们的想要我脚本的证据：  如果放在以前，这种“突然冒出来的小需求”往往意味着要去查资料、找方案、折腾环境，最后还未必真的会做。 因为光是把想法落地，就已经要消耗不少精力。 但现在不太一样了。 很多过去会被我搁置的想法，现在只要我愿意把它说清楚，AI 就能很快帮我把它实现出来。 对我自己来说，这种变化其实挺大的。 它不只是提高了效率，更像是在降低“把一个念头变成现实”这件事的门槛。 以前很多想法，往往是想完就算了。 现在很多想法，是真的可以顺手把它做出来。

一个云服务部署多个项目怎么样呢？

问一下大伙，购买一个4核4G 3M的服务器，想部署多个自己的项目在这台服务器，当然也没有多少访问量的，有没有试过的呢？这样子可行不，不会很卡吧？

摸鱼🐒drawafish.com

代码之外，一次收藏夹自检

# 关键词 1. 网站分享 1. UI 设计 1. 工具网站 # 前言 作为一名冲浪多年的互联网人员，收藏夹有着堆积如山的各种神奇网站，虽然在笔者这边基本吃灰了，但或许刚好有你需要的~ 本期笔者会从<span style="color: red;font-size: 16px">技术视角</span>分享几个有意思的网站，看看有没有你刚好用得上的吧~ # 谷歌地球 (Google Earth)  **技术表现：**<span style="color: red;">★★★★★</span> **实用指数：**<span style="color: red;">★★★★★</span> **地址：** [https://earth.google.com](https://earth.google.com) 一用让人眼前一亮，再用让技术党为之震撼的产品，美丽的蔚蓝色的星球，配合超强的 3D 交互技术，使每个互联网用户都能身临其境的观赏到世界的角角落落，还能当作旅游前的初步路线考察。 不敢想如果上地理课时老师能在大荧幕放这个配合讲解会有多震撼。 **点评：**从开发者控制台简单解析了一下发现有 WebGl、GIS、PWA、WASM、Web Workers、Protobuf 等技术痕迹，笔者虽然没怎么做过 GIS，但 PWA、WASM、Protobuf 和 Web Workers 应该是常与 GIS 项目协作的，否则没法做到这么流畅。至于美术风格是一如既往的谷歌 Material Design +设计，整体极简，且富有沉浸感。    # Bruno Simon  **技术表现：**<span style="color: red;">★★★★★</span> **实用指数：**<span style="color: red;">★★</span> **地址：** [https://bruno-simon.com/](https://bruno-simon.com/) 一个能玩的网站，除了基础交互外，作者还在网页中加入了物理引擎、碰撞音效等，你可以像玩赛车游戏一样，在网站里开车“漂移”，撞倒写着他技术栈的广告牌，或者把车开到对应的区域来查看他的作品和联系方式。可以看作是一个解压网站。 **点评：** 作品集性质网站，表现力非常猛，从控制台上看用到了 pwa 缓存、glb 模型文件、threejs、以及各种贴图和 Web worker 等技术，但实际上要做出这种效果，纯计算机科班是远远不够的，还需要有图形学、美术设计、物理建模等基础。合理怀疑作者前端是副业，主业是学建模的。   # FauxID.com  **技术表现：**<span style="color: red;">★★</span> **实用指数：**<span style="color: red;">★★★★★</span> **地址：** [https://fauxid.com/](https://fauxid.com/) 这是一款地址生成器，虽然可以生成其他税务信息，但主要的还是围绕地址来生成，众所周知，工具型垂类网站，其核心价值在于精准解决用户痛点。因此在开发时，往往会优先保证功能的可用性，而不是在前端性能和交互体验上做过多投入，这个网站就是个典型的例子。 如果各位有线上国际支付的需求，那就需要填写对应的税务信息，当我们不想提供真实信息时，这个网站就完美的解决了我们的需求，同时该网站也是同类型中广告内容最少之一。 **点评：** 网站前端方面没有看出有什么特别的技术，甚至每次生成还得全量加载，大概率前端都没分离，但仔细一想，这是非常合理且合适，首先这种产品大部分用户都是用完即走，不会在网站上停留太长时长，极少情况才会触发其他 UX 交互，其次这样能大幅减少开发时间，作者的商业定位非常清晰，深刻理解这个工具站的<span style="color: red;font-size: 16px">核心是数据，不是交互</span>。    # 蔷薇花园  **技术表现：**<span style="color: red;">★★★★★</span> **实用指数：**<span style="color: red;">★★★</span> **地址：** [https://iirose.com/](https://iirose.com/) 一进来你以为是个游戏，进去一用你以为是聊天平台，再用一会你发现是个社交论坛，操作一下左边菜单，发现是个<span style="color: red;font-size: 16px">大杂烩</span>，聚合了群聊、点播音乐、二手交易、虚拟炒股、内嵌浏览器、广播、发红包等等功能。 **点评：**混合了日系 ACG 游戏、现代极简等风格制作而成，作者在美术与 CSS 方面造诣很深，但由于功能较为繁琐且教程非强制，初感对大龄用户不太友好，社区目前的用户也是年轻二次元居多，从控制台看网络协议有 WS、 http1.1、 http2，以及 jQuery 和 php，缓存机制有 PWA，http1.1 应该是因为要兼容老项目的原因，但是作为一个功能性为主的社交平台，这些无上大雅，<span style="color: red;font-size: 16px">优化要结合实际需求</span>，而且笔者在实际体验中并没有碰到卡顿问题。    # 阿里司法拍卖  **技术表现：**<span style="color: red;">★★★</span> **实用指数：**<span style="color: red;">★★★★★</span> **地址：** [https://sf.taobao.com/](https://sf.taobao.com/) 高级二手交易平台，拍卖一直是一种人们眼中高大上的行为，但借助此网站，平民百姓也可以过过瘾。 这平台有非常多低至百元的货品可以起拍，除了房车地等高价格货品，还有手机、首饰、字画等，虽然东西可能不太吉利，但如果只是用来体验拍卖、以及理解机构的运作是非常不错的。 > 跟电视里的一样，部分货品开拍后会有专门抬价的托，请谨慎出价 **点评：** 从前端技术来看，这个网站确实没有太多花哨的特效，UI 风格也非常务实。但这恰恰说明了它的定位：一个<span style="color: red;font-size: 16px">功能优先、承载复杂业务的平台</span>，网站用户群体也不是一群追求页面好看，高交互的人群，拍卖这种技术架构应该就是从经典的电商技术架构变种而来，说明了一个优秀的技术架构能承载非常多元的业务。    # YUME 梦乡  **技术表现：**<span style="color: red;">★</span> **实用指数：**<span style="color: red;">★★★</span> **地址：** [http://yume.ly/](http://yume.ly/) 非常有意思的梦境记录网站，在这里可以看到别人记录下来的梦以及对其进行留言互动，也可以自己把梦境上传记录，青少年时期是最多梦的时候，如果你们在该网站能看到跟自己做的梦相似的，那或许就很有意思了。 **点评：** 依旧是一个工具性质的网站，UI 风格略古早，http 协议用的全是 1.1 版本，没有特殊的优化，甚至 ssl 证书都懒得配，但正如我上面说的，这类型网站对优化方面要求不高，而且虽然 UI 古早，但看起来没有别扭，经典的卡片式列表布局，间距给得很大，观感还行。   # 总结 网站的类型有很多，工具性的、宣传性的、炫技性的，每种类型的网站在开发过程中注重的点都不一样。 工具性网站通常为了快速解决痛点，都是以最小实现单元来做，加上后续迭代；运营较久的网常为了兼容老代码，通常不会做很多破坏性的更新；产品宣传性的网站，在保证各方面均衡的前提下，通常会尽可能美观；炫技性的网站，通常也是技术最前沿的，很多个人站点也是如此。 作为一名开发者，分析和理解不同产品背后技术取舍的能力——无论是出于性能、成本、商业定位还是历史原因——或许比单纯追逐最新的框架更有价值。因为技术最终是为目的服务的，理解了这一点，才能做出更成熟的工程决策。

分享一个我自己写的工具箱，对我的效率提升不少

> **访问地址：[https://tool.banzhuan.tech/](https://tool.banzhuan.tech/)** 我再工作的过程中，经常遇到一些sql、文本、Excel文件、图片的处理。 为了更高效，写很多脚本，然后把一些通用的模块抽离出俩，做了个工具箱。 欢迎大家来体验 和 提建议 ## 🛠️ 主要功能 ### 📝 文本工具类 - **Unicode转换** - 文字与Unicode编码互转，支持多种编码格式 - **CSV合并** - 多个CSV文件智能合并，数据处理更便捷 - **JSON格式化** - JSON数据格式化美化，提高可读性 - **JSON提取** - 从复杂JSON中快速提取指定字段 - **文本分割** - 灵活的文本分割和格式转换 - **字符串处理** - 批量字符串处理，支持替换、格式化等操作 - **集合比较** - 两个数据集合的差异分析和比较 ### 📊 表格工具类 - **Excel转SQL** - Excel数据快速转换为INSERT语句 - **Excel转UPDATE** - Excel数据转换为UPDATE语句 - **Excel转换器** - 通用Excel转SQL工具，支持多种场景 - **SQL合并** - 多条SQL语句智能合并优化 ### 🖼️ 图像工具类 - **图片批量下载** - 支持批量图片下载和管理 - **图片列表管理** - 图片链接解析和预览功能 ### 📈 图表工具类 - **Mermaid图表** - 在线编辑和生成Mermaid图表

javaweb做的社区养老保险管理系统

# 社区养老保险管理系统 ## 项目介绍 这是一个基于JavaWeb技术栈开发的社区养老保险管理系统，主要用于管理社区居民的养老保险信息。系统采用传统的Java EE架构，使用Servlet + JSP + JDBC技术实现。 ## 技术栈 - 后端：Java EE（Servlet、JSP） - 数据库：MySQL 5.7 - 前端：HTML、CSS、JavaScript - 连接池：JDBC直连 - 项目管理：传统项目结构（非Maven） ## 功能特点 1. 用户管理 - 用户注册 - 用户登录 - 用户退出 2. 保险管理 - 保险信息列表 - 添加保险信息 - 编辑保险信息 - 删除保险信息 3. 权限控制 - 管理员可查看所有用户的保险信息 - 普通用户只能查看自己的保险信息 ## 项目结构 roject ├── src │ ├── dao │ │ ├── UserDao.java │ │ └── InsuranceDao.java │ ├── entity │ │ ├── User.java │ │ └── Insurance.java │ ├── servlet │ │ ├── LoginServlet.java │ │ ├── RegisterServlet.java │ │ ├── LogoutServlet.java │ │ └── InsuranceServlet.java │ └── util │ └── DBUtil.java ├── WebContent │ ├── css │ │ └── style.css │ ├── js │ │ └── script.js │ ├── WEB-INF │ │ └── web.xml │ ├── login.jsp │ ├── register.jsp │ ├── insurance_list.jsp │ ├── insurance_add.jsp │ ├── insurance_edit.jsp │ ├── header.jsp │ ├── menu.jsp │ └── footer.jsp └── readme.md ## 部署说明 1. 创建MySQL数据库，执行insurance.sql脚本 2. 配置src/util/DBUtil.java中的数据库连接信息 3. 将项目导入Eclipse IDE 4. 配置Tomcat服务器 5. 部署运行项目 ## 默认账号 - 管理员账号：admin - 管理员密码：admin123 ## 注意事项 1. 项目使用UTF-8编码 2. 数据库默认使用UTF8MB4字符集 3. 需要配置Tomcat的JDK版本 4. 需要添加必要的JAR包依赖