写一下小作文，感谢一路以来的各位佬的帮助和圈内辛勤奉献的Pter们，没有你们的付出，这个圈子也办法如此蓬勃。

以下内容字数较多，且基本为流水账，主要记录求药历程和心得，不喜勿喷。

然后写的时候已经半夜了，可能写的不知所以，不知道自己说的啥，有问题可以评论，不要骂我，嘻嘻。

历程

从7月7日贴吧处求到星陨阁和末日开始入坑（感谢smallghost佬），学习了如果下载、上传、发种等各项技能，也了解到PT里的各种规则和12大！从此踏上了求💊之路。

7月10日，于贴吧蹲守，早起的鸟儿有🐛吃，在贴吧求到了第一个大站，馒头～（感谢🙏电脑小白乐园！）。从此进入了PT新世界。

原来资源可以这么丰富，下载能够这么快速！也在内部的论坛里了解了其他各大站点的特色，也有了自己的主攻方向！

有了馒头之后，开始过新手任务。中间回归观影，但是无奈属于WEB更新有点慢，虽然资源很全，但是每次新上的，只能通过转载才能获取，这使得我迫切的想要一个WEB专精的站点。

也是在这一个月的折腾里学会了辅种，MP等相关工具的使用。

但是目前我一切的消息来源都是从贴吧接收的，但是贴吧又属于公开场所，不让提及。

转折开始，从贴吧吧主那求得了一个“13城”新站，有了第一个圈子QQ群，从此一发不可收拾，开始疯狂水群，收割各种小站，汲取知识。

在这一个月的摸爬滚打中，时间悄然的来到HH的站庆，也是我从贴吧得知的消息。开始疯狂的求药，想要在这一次站庆中能够入场。

8月18日，玩得早不如玩得巧，我一直是这样认为的，我在各个小站的论坛留言求药，也学会了契约。时也命也，一切机缘就从这开始，我在“13城”的Q群里发求一个HH，可契约，遇到了我PT人生的贵人LT大佬（简写，防止骚扰大佬）。获得了第一个WEB大站，也获得了第一个契约2T一年。

也通过这个群，我结识了几位大佬，带我步入轨道。有L***520佬，甜❤️佬，这几位佬都起到了至关重要的引领作用。

我先是从L***520佬那求到了蜂巢论坛的药，正式进入了PT论坛，里面花里胡哨好好看呀。然后甜❤️佬带我加了一个PT大群！！超级大的那种。

然后在群友道长开发的QQ机器人帮助下，第一时间发现蜂巢在契约不可说，第一次听说但是看到5T500官的要求，有点打退堂鼓。但是LT佬说这是很标准的契约，不过分～我就立马下定了。也是通过我诚恳的发言，以及前面几个月不断的耕耘，以良好的数据求得了这一枚来之不易的不可说,感谢夜佬！至此9月5日，进度3/12。

时光荏苒，在甜❤️佬带我入的大Q群内，我每天打卡水群，因为群里发药看等级，🥹每次抽奖的时候，恨不得自己100级。这里是一个伏笔，虽然我没有抽药的资格，但是我每天坚持水群打卡～～～。记笔记很重要！

时间来到快国庆，收到许多小道消息，说是人、家都国庆会开药，我就私聊我的好上家～LT佬，再得知能够排队后，我欣喜若狂。国庆的前一天。简直是PT的狂欢呀，不可说开药、岛开药（可惜不认识VIP大佬，没有求到），家开药、人开药、重点是2年没开的皇后也开了！！！真是玩得早不如玩得巧，这个站很多人都是卡在11大之后，花钱捐入的。

在国庆0点时候，准时收到了LT大佬的家、人、然后询问皇后也能发，真的欣喜若狂。但是因为2年没开药，突然开药导致皇后的服务器有点扛不住压力，LT佬虽然第一时间给我发药了但是没能成功，然后我也只是等着白天想着恢复了再说，但是凌晨2、3点发现恢复了，然后群内也有大佬在发皇后，我就想着先求了吧，怕到时候满坑了，或者服务器修不好，先进最保险。就找林佬！求了一个皇后，但是再凌晨3、4点的时候LT佬私聊我说发我药的时候，看我有了！真是非常感谢LT佬！至此10月1日，进度6/12。

国庆真的一个慵懒的日子，每天都是中午醒，然后有一天错过了早上的TTG，听说大Q群里发了好多个，有在的都发。好后悔没早起啊。最后发药的大佬也是再群里抽了一波奖，可惜抽了3次药，我是一次没中！！！！天生抽奖黑体。最后得知发药的大佬，是个作家！！！我从旁吹嘘，可能也是把大佬说幸福了！主动找我要📮，给我单独安排了一个！在这边谢谢M佬！至此10月6日，进度7/12。

也是在水大群的时候，一直说找不到🐱上家，有没有大佬能绑定呀～～，深夜总是令人难眠。又是一位大佬(W佬)！他说没发过药，想试试！于是也是热情的把我绑定，起初我还是和他一起蹲守，每天问他今晚有空吗？有的话如果我蹲到药了，能艾特你么～他总是热情的回答～可以的！

到后面我有点怠惰了，感觉🐱真难蹲，我也不敢催佬。毕竟这真是看运气的一件事。中间有几次佬都发信息给我就说就差一点就能发到了。那些都是脚本佬真快！

我也就放弃了。时间总是这么的捉弄人，在一次我和朋友外出散步的时候～QQ的消息突然谈起。

大佬的一句“快点注册哦！”

我瞬间感觉不对！，我是不是得到了什么！！！打开📮，发现了一封邀请静静的躺在那，等我翻阅！

我只能说在我已经不抱希望的时候，谢谢大佬辛苦的蹲守！感谢！

至此10月26日，进度8/12！

岛在11月9号开药，我从大群群主H佬那求的，这怎么求！每日水群，大佬眼熟！仅此而已。非常感谢H佬！（其实这药十一应该就有了，但是岛那会管理都放假。V是节后发的，也算是时间的🪃最后还是扎上了。）这在也还要再次感谢甜❤️佬，因为他已经绑定我要给我发了，但是他的工资还没有发，导致开药了，他还发不上，但是也感谢他的绑定，给我岛最坚实的底气能在这段时间里，有精力去求其他的邀。

11月20日，🌍站庆开药！预约LT佬，得知能发！！！准时获得！！至此进度10/12。

在11月中旬，入了阁的工作组！没错！！！我的入门站，星陨阁！在此我要大篇幅的吐槽！这个阁！奶奶个熊！一个站连个群都没有，害我入门都找不到组织，走了许多弯路。然后自己站长天天在各大Q群，微信群，别站群水挖人！真是该死！！女装阁主！！然后就是这样把阁主给PY了，求到了💊论坛，求到了最难求之二🈳。至此12月3日，进度11/12！

没错，我的最后一站竟然是月月，那个有3.3T就能搞到药的月月，不是我没有空间，只是我想下一些自己能够选择的资源，所以一直得不到药！最后还是感谢LT佬，他带我入了🐸！我从🐸坚持不懈的发育。终于在今天通过官邀，等到了月月邀请，至此12月13日！进度12/12，内站大圆满！！！

心得总结🆕

1. PT是个比较私密的圈子，大家都要遵守规则，这样这个圈子才能长久的发展。

2. 求药适合在各大站内论坛以及Q群微信群，贴吧很多🈲求，如果我能从Q群起步的话，可能毕业的更快。

3. 脾气要好，求💊懂得谦虚，这是一个分享的圈子，没有什么是对方理所当然应该付出的。（这期间遇到过许多发言惊人的大神，反正圈子很小大家也都知道是哪些人）

感谢🙏汇总

前面感谢的太分散，这边把名单再总的写一下（不仅限于写的这些，这些是长聊且大站发药的上家，还有许多发中小站的大佬也给予我许多的帮助，这边就不一一列举，也是非常感谢！）

1. LT佬

2. L***520佬

3. 甜心佬

4. 道长

5. 林佬

6. 恒佬

7. 慕佬

8. W佬

9. 夜佬

10. 👚阁主

11. 电脑小白乐园

🧨🧨🧨🧨🧨🧨🧨🧨🧨🧨🧨🧨🧨🧨🧨🧨

前段时间在整理技术方案时，想起了之前公司的那个项目架构。我们当时做了一个中台系统，配合各种业务模块，效果还挺不错的。简单说就是：

• 有个中台统一管理所有应用

• 各个业务模块独立开发、独立部署

• 前端也是模块化的，可以动态加载

• 整个流程都是自动化的

总结一下原公司的架构可能为“中台 + 模块化微服务 + 微前端”结合的云原生架构体系，特点是：

• 中台统一管理：负责应用注册、菜单、权限、页面路由管理

• 模块化微服务：业务模块独立开发、独立打包、独立部署，Kubernetes 管理生命周期

• 前端微前端/模块化页面：业务页面可在中台中集成展示

• CI/CD 构建流水线：模块从开发到部署全自动化

为什么要折腾插件化？

生命在于折腾。

在逛各位大佬们的博客的时候有幸遇到很多优秀的博客，其中不乏有一些独立开发的站点并且开源。

不过有些开源站点他设计的功能会很丰富，导致很多人可能用不上部分功能，所以导致功能冗余占用性能（虽然也只是蚊子腿）。

就好比说博客网站可能主要的就是博客列表、博客详情，除了一些强耦合在页面里的功能如：评论、推荐、总结等功能不能拆分的。

很多开源站点还支持履历、设备展示、照片墙、数据统计、旅游地图等这种单开一个页面的功能，那实际用户使用的时候可能就没有照片墙或者设备需要展示，这几个页面甚至是对应的查询api和库都是不需要的。

这次重构博客的时候我有在思考，博客本质就是文章，其他的内容能不能按类似的方案开发，比如添加一些功能模块，比如：

• 图书角：展示我读过的书

• 影视墙：记录看过的电影电视剧

• 旅游足迹：分享旅行经历

• 友链管理：方便管理友情链接

但是这套架构在企业环境里确实很香，但当我想要给自己的博客搞类似功能时，发现完全不是那么回事，其技术栈复杂、开发周期长、运维成本高，对于一个个人使用的博客而言无异于是“杀鸡用牛刀”、“大炮打蚊子”。

在前面几月折腾PT的时候发现了一个项目，使用了插件化的开发思路，为此我想借鉴一番。（玩PT的程序大佬是真的多，一个项目里学到好多东西）

用插件来注册对应需要拓展的页面，实现功能的扩展，方便开源后，用户们的自行组装，有点搭积木的意思。

AI加持，尝试“云”架构一波

最近没时间验证，尝试把想要使用的架构和逻辑思路丢给AI，不断的沟通修正，让他回答出一份看似可行的技术架构说明。

以下只是一个方向，还待验证

技术选型策略

分析"前端模块联邦 + 后端插件管理"的技术路线：

前端技术选型：Module Federation + Nuxt

Module Federation是Webpack 5引入的革命性特性，它允许JavaScript应用在运行时动态加载远程模块。这一特性完美契合插件化架构的需求：

• 动态加载：主应用可在运行时动态加载插件的前端UI和逻辑

• 依赖共享：可配置共享依赖，避免重复加载

• 独立部署：各插件可独立开发、独立部署

后端技术选型：PF4J框架 + SpringBoot

PF4J（Plugin Framework for Java）是一个轻量级的Java插件框架，它提供了：

• 插件生命周期管理：支持插件的安装、启动、停止、卸载

• 扩展点机制：通过扩展点实现插件与主应用的解耦

• 类加载隔离：确保插件间的类冲突不会影响主应用

核心组件职责

主应用职责：

• 提供基础网站功能（博客、个人信息、主页等）

• 维持轻量级和稳定性，不受插件逻辑影响

• 负责插件的发现、加载和管理

插件系统职责：

• 支持功能的动态添加、移除和升级

• 每个插件独立开发、独立部署

• 实现具体业务功能（图书角、影视墙、旅游足迹等）

模拟演练

阶段一：开发阶段

前端项目开发：

1. 创建独立的book-ui项目

2. 配置Module Federation，暴露./BookPage组件

3. 构建产出dist/目录

后端项目开发：

1. 创建book-plugin项目

2. 实现MenuExtension接口，注册菜单项

3. 实现RequestExtension接口，处理/books/list请求

4. 将前端构建产物放入后端资源的static/目录

打包发布：

将后端JAR和前端资源打包成book-corner-1.0.0.zip发布包

阶段二：部署安装阶段

1. 在个人网站后台上传插件ZIP包

2. 主应用后端使用PF4J解压并加载JAR文件

3. 检测到MenuExtension，将菜单信息存入数据库

4. 检测到静态资源，建立文件映射：http://api.site.com/plugins/book/assets/

5. 执行插件内置的init.sql，创建plg_book_table表

阶段三：运行阶段

1. 用户访问首页，前端Shell请求/api/config获取配置

2. 后端返回插件配置信息，包括模块名称、入口文件地址、路由路径

3. 前端Shell根据配置生成"图书角"菜单项

4. 用户点击菜单，前端动态加载remoteEntry.js文件

5. 渲染远程组件，组件内部发起API请求获取数据

6. 后端拦截请求，转交给book-plugin处理，返回JSON数据

技术优势分析

极致的模块解耦

• 各插件完全独立，互不影响

• 插件升级不会影响主应用和其他插件

• 支持并行开发和部署

主应用轻量化

• 核心功能精简，启动速度快

• 内存占用低，运行效率高

• 稳定性不受插件质量影响

开发效率提升

• 插件开发者只需关注具体业务逻辑

• 标准化的接口降低了开发门槛

• 支持快速原型验证和功能迭代

个站优化

考虑到是个人博客，一个人可以做一些简化：

1. 统一技术栈，使用相同版本，避免版本冲突，减少插件体积。

2. 数据库简化，使用一个实例，前缀区分表明、安装建表，卸载删除。

架构升级

当插件量增大（如几十到上百个）时，核心矛盾从「单一插件的前后端协同」转变为「规模化插件的高效管理、性能控制、隔离稳定性、生态标准化」。

原方案的核心架构（MF + PF4J）仍适用，但需要在「加载机制、管理平台、隔离策略、性能优化、生态规范」五个维度进行升级，以下是具体落地方案：

核心升级思路

规模化插件的核心需求是：「平台化管理 + 轻量化运行 + 强隔离 + 低损耗」

• 管理层面：从「手动加载插件」升级为「插件市场 + 统一管理平台」，支持插件的搜索、安装、升级、卸载全生命周期管理；

• 加载层面：从「全量加载」升级为「按需加载 + 预加载策略」，避免大量插件同时加载导致的性能问题；

• 隔离层面：从「基础隔离」升级为「强隔离（沙箱化）」，防止插件间的依赖冲突、数据泄露、资源抢占；

• 性能层面：通过「缓存、资源优化、异步处理」降低大量插件对主应用的性能损耗；

• 生态层面：通过「插件开发规范 + SDK」标准化插件接入，降低多开发者协作的成本。

当插件量增大时，原方案（MF + PF4J）通过「平台化管理 + 按需加载 + 沙箱隔离 + 标准化生态」的升级，完全可以支撑大量插件的稳定运行，核心优势：

1. 管理效率：插件市场 + 管理后台解决了大量插件的安装、升级、卸载、监控问题，无需人工干预；

2. 性能可控：按需加载 + 资源优化 + 隔离策略，避免大量插件导致的加载缓慢、内存溢出、资源抢占；

3. 稳定性保障：强隔离（前端沙箱 + 后端类加载器 / 多数据源）+ 健康检查 + 熔断，防止单个插件异常影响全局；

4. 生态可扩展：SDK + 规范 + 审核机制，降低第三方开发者的插件开发成本，形成良性生态。

落地优先级建议

1. 先搭建「插件市场 + 管理后台」，解决大量插件的管理问题；

2. 再优化「加载机制 + 隔离策略」，保障性能和稳定性；

3. 最后完善「SDK + 规范 + 审核机制」，支撑生态扩展。

适用场景边界

• 适合插件量：100 个以内（个人网站 / 中小型平台），通过上述方案可稳定支撑；

• 若插件量超 1000 个（大型开放平台），需进一步升级为「微服务化插件」（每个插件独立部署为微服务，主应用通过服务发现调用）

抽象总结

这篇博文的核心内容多由 AI 生成 —— 只因文中架构尚处于 “构想阶段”（是我 “云” 出的思路，未经过实际落地操作）。

但想借这点说明：AI 虽无法独立完成完整应用的开发，可只要我们提供明确的架构方向与逻辑，让它参与讨论、验证，它就能在关键环节帮我们排查漏洞、修正偏差。

带着思路和 AI 协作的方式，远比直接把问题丢给 AI、收到格式生硬的回复要舒服得多，对渴望成长为架构师的新手来说，这无疑是个实用的辅助功能。

也算是水一篇博文了，不然直接拷贝AI回复也太抽象了。

之前改博客都是直接在生产环节直接操作Mysql库，最近再重构和修改BUG，所以打算本地也搭建一个Mysql，但是不想用安装包的方式安装，就使用了docker安装在本地。电脑上使用的DataGrip来管理数据库的，他没办法像Navicat直接远端拷贝过来，所以想办法弄一个快速同步的方案。

过程

搭建本地mysql

services:
  mysql:
    image: mysql:8.0.41
    container_name: mysql8
    restart: unless-stopped
    ports:
      - "3306:3306"
    environment:
      MYSQL_ROOT_PASSWORD: rootpassword123
      MYSQL_DATABASE: nuxt3_blog
      MYSQL_USER: myuser
      MYSQL_PASSWORD: mypassword

执行docker compose -f mysql_docker.yml up -d创建容器

# 远端数据库配置
REMOTE_HOST=10.0.0.8
REMOTE_PORT=3306
REMOTE_DB=prod_db
REMOTE_USER=admin
REMOTE_PASS='Abc123!'

# 本地 docker 容器 MySQL 配置
LOCAL_CONTAINER=mysql8
LOCAL_DB=mydatabase
LOCAL_USER=myuser
LOCAL_PASS='mypassword'

设置后，你只需执行：

docker exec -i "$LOCAL_CONTAINER" sh -c \
  "mysqldump -h $REMOTE_HOST -P$REMOTE_PORT -u $REMOTE_USER -p$REMOTE_PASS $REMOTE_DB" \
  | docker exec -i "$LOCAL_CONTAINER" mysql -u "$LOCAL_USER" -p"$LOCAL_PASS" "$LOCAL_DB"

即可自动完成远端 → 本地容器的导入。

最近再重构博客文本的代码块，用上了AI帮忙生成了React的代码样式，照搬到了Vue发现样式有问题。

排查

<pre className="m-0 p-0 bg-transparent font-mono text-sm leading-6 text-gray-300" style={{ tabSize: 2 }}>
  <code>
    {lines.map((line, i) => (
  <div key={i} className="whitespace-pre group/line">
    {/* Simple pseudo-syntax highlighting wrapper */}
    <LineContent line={line} />
  </div>
))}
  </code>
</pre>

上面的是react的代码，下面的是vue的代码

<pre class="m-0 p-0 bg-transparent font-mono text-sm leading-6 text-gray-300">
  <code>
    <div v-for="(line ,index) in lines" :key="index" v-html="highlightedCode(line, language)"/>
  </code>
</pre>

vue的效果就是和react差距在react的可以和行数对齐，vue的上下都会留白。我检查了react项目中的其余css样式，也都没有单独针对<pre>标签的，我发现在vue中将<pre>改为<div>就不会上下留白，我当时初步怀疑是样式问题，所以一直再找2者之间的区别，后面单独在react项目中的html文件里也写了同样的<pre>代码，发现也有留白，我就一直怀疑是不是react是不是有什么特殊处理。

在我遍寻AI和Google的时候都没法解决的时候，尝试问了一下热心的群友，他当即给我发了下面三张图片，以解我的疑惑。

反思

这次踩坑就是自己的基础太差没有打牢根基，因为这种小问题也是浪费了4个小时再排查。

这篇博客也是加以反思吧。还有就是有问题多问，不要闷头干，说不定别人的一句话就能点醒你。😭

最后也是查了一下为什么react可以，vue不行。以下是Chatgpt的回答

最近有位博主在博客上留言，说是在RSS Guard 和 QuiteRSS中本站的RSS订阅失败，我看到后也是开始研究，之前写这个RSS的时候也只是参考了一些博主的RSS格式，只是通过了RSS格式验证，并没有导入阅读器验证，这次反映了问题正好一试。

解决

这次我将自己的RSS和参考的RSS拉出来对比，并且补全了缺失的字段，导入RSS Guard，发现还是插入失败，查看日志说是数据库插入问题。

对着报错的那条数据改来改去也都失败，后面把我的title标签和description包裹的CDATA去掉，就行了。

所以目前理解为RSS Guard的标题和描述不支持CDATA包裹吧。

致谢

感谢博主「崔话记 - 向着理想的方向，爬一会儿，躺一会儿」的问题反馈和RSS模板支持。

一、标题格式（核心结构）

剧名 [季集信息] [年份] [其他信息] 分辨率 [地区码] [内容分发方] 片源类型 [规格] [HDR类型] [bit信息] 视频编码 音频编码 [声道数] [对象信息] [音轨数]-制作组

二、字段说明

剧名

• 必填。优先使用英文名；无则可用罗马音或中文。

• 动画推荐用 MyAnimeList 标题。

[季集信息]

• 单季：S01

• 分集：S01E03

• 多季合集：S01-S03

[年份]

• 有重名或合集时必填（例：2014-2018）。

• 单集节目（综艺/体育）写完整日期 20240326。

[其他信息]

• 特殊版本：Director’s Cut、Extended、Uncensored

• 更新版：REPACK、RERIP、V2、PROPER

• 特殊比例或混源：IMAX、Open Matte、Hybrid

分辨率

• 必填。取自 MediaInfo → Height + Scan type

  • 示例：2160p / 1080p / 720p

• 不允许写作 4K / 2K。

[地区码]

• 原盘类（Blu-ray、DVD）填写：JPN、USA、HKG 等。

[内容分发方]

• 流媒体：DSNP（Disney+）、NF（Netflix）、AMZN（Amazon）等。

• 碟片发行方：CC、MOC、MAC 等。

片源类型

• 原盘类：Blu-ray、UHD Blu-ray、NTSC DVD9

• 压制类：BluRay、DVDRip

• WEB类：直接用分发方（如 DSNP、NF）

[规格]

• 常见：Remux、WEB-DL、WEBRip、HDTV

• 原盘类不填写。

[HDR类型]

• 常见：HDR、HDR10+、DV、DV HDR

• 无 HDR 信息则不写。

[bit信息]

• 仅 AVC 且 10bit 时写 Hi10P。

• x265 不写 10bit。

视频编码

• 原盘：AVC、HEVC、MPEG-2

• WEB：H.264、H.265、AV1

• 压制：x264、x265、AV1

音频编码

• 常见：FLAC、DD（AC3）、DDP（E-AC3）、DTS-HD MA、TrueHD

• AAC/MP3 且为 2.0 声道时可省略声道数。

[声道数]

• 示例：2.0、5.1、7.1

• 从 MediaInfo → Channel layout 获取。

[对象信息]

• 若含全景声技术则写：Atmos、Auro3D。

[音轨数]

• 多音轨写：2Audio、3Audio。

• 单音轨不写。

制作组

• 必填。格式：-制作组

  • 例：-StarfallWeb

  • 来源不明写 -NoGroup（慎用）

然后使用Nuxt UI自带的脚手架安装就没有报错。检查了package.json文件，发现都一样的也不知道，为啥构建出来的不一样。只能按照脚手架的目录，把博客的文件一个一个向脚手架靠拢。

最后还是折腾了快2个小时才发现问题所在，后面也在官方文档处找到答案了，所以在这边吐槽一下，看文档要仔细，白瞎了自己这双眼。

If you’re using pnpm, ensure that you either set shamefully-hoist=true in your .npmrc file or install tailwindcss in your project’s root directory.
如果您使用的是 pnpm，请确保在 .npmrc 文件中设置 shamefully-hoist=true 或在项目的根目录中安装 tailwindcss。

一开始是图标和文本不在同一行上了。

原先还以为是自己重构后的组件样式有问题，把原先的样式拷贝过来后，依旧如此，后面把Tailwind CSS去除了才发现正常了。

Chatgpt一下说是提供了一套“预设的基础样式（preflight）”，基于Normalize.css 做了调整，以确保不同浏览器的默认样式更一致，同时移除一些不必要的默认样式。

所以针对他改动了

display: block;
vertical-align: middle;
max-width: 100%;
height: auto;

把原先的inline改成block，新增了max-width，这也太坑了。

后面我手动把block改回inline，他们总算在一行上了。

但是我发现a标签撑不满div了！！！

我也是醉了，TailWind CSS为了确保不同浏览器的默认样式更一致，同时移除一些不必要的默认样式。“真是好心办坏事”（新手不懂哈）。

chatgpt解释为什么要加 max-width: 100%

1. 防止图片撑破父容器

   • 在原生浏览器行为下，<img> 默认按图片本身尺寸渲染。

   • 如果父容器宽度小于图片宽度，图片就会溢出容器。

   • max-width: 100% 可以让图片最大宽度不超过父容器宽度，从而保证布局不会被撑坏。

2. 响应式布局友好

   • 在不同屏幕或父容器宽度变化时，图片会自动缩放。

   • 避免在小屏幕上图片撑出边界。

3. 配合 Tailwind 样式体系

   • Tailwind 的大部分布局类都是基于 flex / grid / container width。

   • 如果图片超出容器，flex 布局可能失效或者造成滚动条。

   • max-width: 100% 可以保证图片在 flex/grid 中可控。

但是在这边确实就是影响效果了。哎，只能说每一次重构都是坑啊。吸取教训，再此记录一下，折腾2个小时。

今天周末去爬了天马岭登山道，整体感觉还算轻松。可能是因为为了下午的登山，中午煮了一大锅的米饭～狠狠的补充了一波碳水。

嗯～可能也是快要入冬了，下午出发的也不感觉炎热，山里面树荫还是很舒服的，山风一吹，渐感微凉～

那也不至于感冒😷～～

途中也有许多比较有趣但不理解的点，一个两人宽的登山道上为什么会在靠近斜坡的那一边搭一个帐篷，这点我很费解。

沿途的人还有遛狗的，带小孩上来画画的，尤其是那个画画的小孩我比较好奇～那个画卷和卷轴一样老长了，但是为啥会有🐟，这就是小孩丰富的想象么。

走到半途中发现一只尾巴很长的不知道是鸡还是什么～远远看到，走近的时候去飞走了，没来得及看照。

然后分享一张登山途中拍的随手照，算是健身打卡啦～

看🔥车

看🔥车，顾名思义，就是看着火的车子。

没错～这是我第一次现实现场看到车子着火。

在回家的路上，一辆车子在十字路起火了，我那那会骑着小电驴冲过去的时候可吓得不行，生怕刚过去就爆炸了。

我也是佩服那些开车的人，怎么一辆车着火了，他们还能停在他们旁边等红绿灯的，这点我实在是想不通。

是因为我小电驴是肉包铁，他们小车是铁包肉，不怕炸么。这些人才是真的勇士啊～

虽然有公网IPV6，但是不想把所有的设备都映射出去，只能自己搭建一个回家VPN隧道。

之前有使用过hwdsl2/ipsec-vpn-server的docker搭建过一个，但是之前的环境是有IPV4公网的。这次家中仅有IPV6的环境，在github上问了作者，说是不支持只好作罢。

在谷歌搜索上发现WireGuard是支持IPV6回家的，刚好满足我的诉求，所以开始着手搭建。

起先也是照着视频博主使用的WireGuard Easydocker部署，但是发现一个问题。原本就是宿主机加容器，然后docker里又有一层WireGuard的网卡，多层的NAT弄的我也是看不懂。博主装完服务以后，手机扫码直接可以就可以访问内网了，也没有添加路由等其他操作。而我却是不行。问了DeepSeek、ChatGPT、豆包，都说加路由配置，但都说不清楚是哪里加哪个笔记太多层了。可能也是我表达的有问题，反正就是折腾了一晚上，不了了之，能连上无法访问内网！！！（这边知道原理的朋友也欢迎留言指导一下，毕竟折腾了通宵没搞定）。

可用实操

接下来就是我弄通的实机操作了，先分享一下软路由的版本和配置，我记得低版本的是没有带WireGuard的。

| 主机名 | iStoreOS | | --- | --- | | 型号 | FriendlyElec NanoPi R5S LTS | | 架构 | ARMv8 Processor rev 0 | | 目标平台 | rockchip/armv8 | | 固件版本 | iStoreOS 24.10.4 2025102410 / LuCI openwrt-24.10 branch 25.295.16898~9fec633 | | 内核版本 | 6.6.110 |

网络-接口-添加新接口

名称：WireGuard（随意你认得就行）

协议：WireGuard VPN

编辑刚才创建的接口-常规设置

私钥、公钥（这两个使用生成新的密钥对，自动生成即可）

监听端口：51820（这个随意填不冲突就好，后面需要到防火墙那放行对应端口）

IP地址：10.8.0.0/24（相当于又一层NAT，属于WireGuard的子网段，不能和当前的主网段一致）

常规设置切换到-防火墙设置

我是直接把lan的防火墙也分配给了wireguard，如果有特别配置可以自己建一个新的

常规设置切换到-对端设置-添加对端

描述：随意

公钥、私钥、密钥（都直接生成）

允许的IP：10.8.0.2（这个很重要，很容易搞混，这个是给WireGuard客户端分配ip用的）

路由允许的IP钩上

端点主机（有DDNS域名的直接填域名，没域名的填公网ip）

端点端口（就填放行的那个）

持续保持连接（用建议的25）

配置文件导出-生成一下二维码给手机扫

允许的IP（0.0.0.0/0指手机的所有流量都通过wireguard代理，如果只是想要访问内网，改成内网的比如10.0.1.0/24）

DNS服务器（就Istore默认用的那个就行）

地址（10.8.0.2，之前配的WireGuard网段）

保存并应用一下配置

防火墙放行

网络-防火墙-通信规则

总结

折腾了半天终于是搞定了IOS的，后续如果遇到其他设备端的问题再来补充

技术参考

OpenWrt 搭建 WireGuard 服务端使用指南 - 爱一枝梅

GitHub - wg-easy/wg-easy: The easiest way to run WireGuard VPN + Web-based Admin UI.