- 博客(54)
- 收藏
- 关注
RSS订阅原创 从零跑通第一个 Agent（附完整可运行代码）
用 Credential、Model、Agent、Msg 四个对象跑通第一个 AgentScope 2.0 智能体，代码单文件可直接运行，含 DeepSeek、混元、百炼三厂商接入与 3 个常见报错的排查路径。
2026-10-23 08:56:22
374
1
原创 微信支付调起报 access_denied
公众号H5支付调起失败，报错system:access_denied，根源常在授权配置而非前端逻辑。关键排查步骤：先查后端支付记录表，确认return_code=SUCCESS且err_code_des为空，确保下单成功；再核对商户平台四要素——APPID已授权、JSAPI权限开通、支付目录包含当前域名、公众号为已认证服务号；同时关闭PAY_SIMULATE等模拟开关，验证证书路径与序列号一致。若仍失败，检查URL长度（<200字符）及域名是否被限制。核心原则：先确认后端下单成功，再定位前端鉴权问题，避免盲
2026-10-22 06:29:37
246
原创 微信内打开显示请部署验证文件
不在白名单里的域名，用户在微信里点开就会被微信接管，跳到它自己的一张提示页，也就是你看到的这一张。微信给你一个随机文件名和一段随机内容，你让这个域名能正确返回，微信的服务器来抓一次，抓到而且内容一致，域名才被放行。有请求而且 200，却仍然显示校验失败，说明你已经做完了该做的事，别再去动服务器配置，回平台重新发起一次校验。日志里是请求加 200，说明微信已经抓到了，而且成功了，服务器侧没问题，问题在公众平台那边，回平台重新提交。HTTPS 正常，证书正常，接口返回 JSON，浏览器里 H5 打开也正常。
2026-10-21 06:35:50
229
原创 微信校验文件不用文件
H5站点迁移后，为通过微信业务域名校验，采用Nginx精确匹配+return直接返回40字节校验内容的方案。避开了文件系统与容器依赖，实现零配置变更、跨站点通用、容器重建无感。关键点：使用location = /xxx.txt精确匹配，return 200 '...'严格40字符无换行，default_type text/plain，并确保配置生效与主站稳定。备份验证、语法检查、路径测试缺一不可，最终以最小成本完成微信校验。
2026-10-20 06:12:45
588
原创 curl resolve 和 Host 头的两种免 DNS 验证 HTTPS
本文分享了在不切换DNS的前提下，通过curl -H和--resolve精准验证站点路由、HTTPS证书及反代规则的实战方法。核心在于：服务器依据HTTP Host头识别站点，而非DNS解析；--resolve可局部伪造域名解析，实现安全验通。作者建立“先验后切”流程——先用Host头验HTTP路由与后端健康，再用--resolve验TLS与证书，确保三站配置无误后再切DNS。同时强调提前降低TTL至60秒，保障快速回滚。整个过程无需改hosts，命令可复现，极大降低发布风险。
2026-10-19 06:00:01
624
原创 证书签不下来，是因为 well-known 被反代了
证书签发失败常因反向代理拦截ACME验证路径。CA通过访问/.well-known/acme-challenge/验证域名所有权，但若该路径被统一反代至后端容器，将返回404。解决关键：在Nginx配置中，于location /前添加独立规则，使该路径由面板直接响应，且root路径需使用容器内真实路径（如/www/sites/...）。建议签发前预检：放探针文件并用curl -H "Host:..."测试能否获取内容，确认路径归属。避免误判为端口或DNS问题。签发后及时清理探针，并确保新证书能自动续签，切记
2026-10-18 14:54:25
442
原创 一个域名两个后端
三个容器都起来了，本机直连端口全通。可浏览器打开前端域名，首页能出来，一登录、一进列表，控制台一排 404。所有 api 都 404。 先把背景说一下。用户不直接连你的容器，而是先连到面板的 Web
2026-10-18 05:47:48
329
原创 备份包只有 1.5K?
备份仅1.5K却未包含任何站点配置，因命令误用find ... | head -1 | dirname导致仅打包默认conf.d目录。正确做法应全量收集.conf文件，用-T -整体传入tar，并通过tar -tzf | grep 域名验证内容。备份需带时间戳、强制验证，且以nginx -T确认实际加载配置来源。改前基线校验（curl + Host头）与改后对照不可少，影响整机9个站点。体积异常即警报，验证是备份的必要环节。
2026-10-17 15:54:22
399
原创 超时 8 秒，让我误判服务器访问不了 GitHub
迁移开始前要做放行检查，其中一项是服务器出网能力。 我在检查表里写下的探测命令是这样的。 回显是空的。于是放行表上多了一行判定，可达 github.com，实测不通，空响应，需要改路线。 结论一落地，
2026-10-17 06:24:24
390
原创 静态统计 SQL 时必须连 DELETE 一起看
新服务器数据初始化脚本首次运行，表数量33条通过，唯独v2_site_config仅24条未达标。追溯发现，此前对插入总数56条的估算忽略8条DELETE清空操作，导致预期值虚高。实则seed.sql清空后重建，最终24条为正确结果。教训：统计SQL必须同步计删、写、建操作，判据需实跑校准并固化流程，辅以ON_ERROR_STOP确保错误不被静默掩盖。
2026-10-16 16:00:33
376
原创 旧 SQL 在新 PG 上能不能跑
跨版本迁移风险源于行为变化而非语法不兼容。虽逐项核对了PG 15+语法，但真正验证依赖ON_ERROR_STOP=1的实测导入——6个脚本1671行SQL一次通过，33张表结构完全匹配。静态统计曾误判表数与行数，凸显人工推演不可靠。最终以执行器为判决书，让错误在第一现场暴露。Redis部分同理：仅用6个基础命令，兼容性明确；默认持久化策略可接受短期数据丢失。核心原则：先厘清“用了什么”，再以实测验证“能不能用”。
2026-10-16 06:45:31
219
原创 密码正确，PostgreSQL 提示 no pg_hba.conf entry
容器连接PostgreSQL失败，根源在于pg_hba.conf未放行容器网段。尽管网络与密码均正确，但数据库仅允许127.0.0.1访问，而容器源自172.18.0.4私网地址，被拒之门外。解决方法是将数据库访问权限设为“所有主机”，使HBA规则放行0.0.0.0/0。配合端口绑定127.0.0.1:5432，实现外层隔离、内层开放的安全架构。通过分层诊断：先查网络，再验授权，最后核凭证，可精准定位问题，无需重启或改代码。
2026-10-15 17:09:25
489
原创 Docker 容器名 ping 不通
容器间无法通信因网络隔离所致：面板与 Compose 分别创建独立 bridge 网络（1panel-network 与项目默认网），导致容器名解析失败。解决方案是显式声明 external: true 复用已有网络，并通过 docker compose config 验证配置正确性。最终使用临时容器测试连通性，确保网络、DNS、认证、服务端均畅通，实现安全可靠的内网直连。
2026-10-15 05:17:26
523
原创 你容器里跑的镜像，可能不是 latest 指向的那个
打包前镜像与容器版本不一致，源于 latest tag 可变而容器绑定固定镜像ID。实测发现容器运行的是旧镜像，而 latest 已指向新构建版本，导致上传错误。根本原因：容器创建后镜像绑定固化，latest 指针可被覆盖。解决方法：每次打包前用 docker inspect 和 docker images --no-trunc 比对容器与 tag 的完整 sha256 ID，不一致则执行 docker compose build + up -d --force-recreate 强制重建，确保两者同步。关
2026-10-14 16:14:21
355
原创 docker build 跑了 92 分钟还是失败了
Docker Compose 构建因网络中断（short read）失败，但分析表明问题出在镜像源不稳定，非代码问题。通过比对镜像构建时间与源码修改时间，并用镜像内运行的 Python 逐文件计算 md5，确认 app-admin 镜像内容与本地代码一致，可直接复用。其余两镜像因源码更新需重建。关键经验：遇 network error 先分清是否影响代码，用时间线+md5验证旧镜像可用性，避免无效重试。注意 Windows/MSYS 环境路径转换坑，用 chr(47) 或 // 绕过。
2026-10-14 05:51:22
411
原创 服务器不能编译怎么办
接到迁移任务的时候，新服务器是 4 核 8G，装了 1Panel 面板。 旧机要下线，三端服务整体搬过去。 三端指的是一个 H5 静态站、一个 Go 后端、一个 Python 管理后台。 真正的麻烦是
2026-10-13 16:54:32
212
原创 DNS 已经切走了，服务还没起来
DNS提前切换致服务中断，但意外打通证书签发路径。通过本地验证排除代理污染，确认问题根源在容器未启动。以“容器启动”为恢复临界点，重排优先级：先建目录、上传、配置、启容器，再签证书，联调与加固延后。杜绝顺手优化，确保恢复效率。关键经验：错误码带OS特征即本地污染，本机直连验证最可靠。
2026-10-13 06:04:43
568
原创 上线成功的标准不是你的站跑通
部署时仅验证自身站点通断，无法确保不影响共用配置的其他业务。因 OpenResty/Nginx 配置平铺共享，一次 reload 可能悄悄破坏他人站点。正确做法是：动配置前备份整目录并验证，改后用 for 循环全站校验状态码基线，差值异常立即回滚；同时检查 server_name 重复问题。三步走：备份→验证→语法测试再重载，确保安全可控。
2026-10-12 05:41:46
482
原创 一台 4 核 8G 已经跑了 6 个站点，我是怎么把第 7 个塞进去的
接到迁移任务的时候，目标服务器是 4 核 8G、200G 磁盘，上面装了 1Panel 面板。 听起来是一台很普通的机器。真正让它难办的，是后半句。 这台机器上已经压着别人的线上流量。 当时在面板里数
2026-10-11 05:59:04
549
原创 .env 的三个必查项
2026年9月17日部署ThinkPHP 8.1.4应用时，因.env配置错误导致服务异常。核心问题包括：DB_HOST误设为127.0.0.1，应改为MySQL容器名；DB_PREFIX必须留空，否则表名拼错；APP_DEBUG需先开启以排查故障，验收后关闭；JWT密钥须≥32字节（建议openssl rand -hex 32生成），且用户与管理员密钥不可相同。此外，.env权限应设为600，避免凭据泄露。所有配置变更应通过文件编辑而非1Panel面板，以防容器重建丢失依赖。
2026-10-10 05:09:28
601
原创 SQL 脚本的导入顺序
六个SQL脚本按文件名1到6顺序执行时，因依赖顺序错误导致第248行报错“表不存在”，批处理模式下遇错即停，后续语句全部跳过。虽验收通过（表数、字符集、数据抽查均正常），实则缺失6张关键表。根源在于脚本编号按编写顺序而非执行依赖排序，正确顺序应为1→3→2→4→5→6。通过静态扫描表创建与引用关系可提前发现依赖问题，且建议所有建表使用IF NOT EXISTS以提升幂等性，避免重跑失败。
2026-10-09 05:50:31
281
原创 composer.lock 反查
部署PHP项目时，扩展配置不应依赖经验或通用清单。正确做法是基于composer.lock解析生产依赖，通过composer check-platform-reqs --no-dev和锁文件分析，精准提取必需扩展（如ctype、fileinfo、json等）。此外，还需补充工具层（如zip）和代码调用项（如bcmath），并通过实测验证。最终清单分三层：强制依赖（Composer校验）、工具依赖（部署时暴露）、可选优化。避免仅凭面板显示启用即判断加载成功，应使用精确匹配核验扩展状态，确保线上无500错误。
2026-10-08 06:13:37
434
原创 MySQL 升到 8.4 前的兼容性自检清单
8.0 是 2018 年 4 月 19 日 GA 的，一路服役了八年。很多生产库现在还跑着它。大部分人第一次听说要升级，是在一份安全扫描报告里。升级教程到处都是，讲怎么升的居多。少有人讲升之前该查什么。
2026-10-07 06:00:27
533
原创 repo 与 index：站点目录该怎么切
站点目录应仅存放运行所需文件，代码仓库须置于站外（如 /opt/repos/<域名>），通过 git pull + rsync 同步至站点目录。避免在站点内克隆仓库，以防删站时数据丢失或 .git/ 暴露于 Web 权限下。使用 rsync -a --delete 时需显式排除 8 项（如 .env、vendor/、runtime/、public/storage/ 等），确保关键文件不被误删。同步后务必检查 vendor/autoload.php、.env 及 runtime 可写性，确保部署成功。核心原则
2026-10-06 05:44:25
556
原创 页面打不开不是 Nginx 的错
部署成功却页面打不开，看似配置问题，实则根源在依赖缺失。vendor/ 和 .env 因 .gitignore 与 rsync 排除清单被遗漏，导致 PHP 加载失败、框架无法启动，表现为空白页或无法访问。修复需手动执行 composer install --no-dev 并补全环境配置。后续发现接口地址错误，实际路由路径不符，经修正后接口正常响应。问题层层暴露，揭示了“排除即不生成”的部署陷阱：必须明确排除后的文件由谁创建，否则极易漏掉关键依赖。
2026-10-05 03:34:07
646
原创 宿主机路径与容器路径
在1Panel中，php.ini文件通过bind mount在宿主机与容器间共享：宿主机路径为/opt/1panel/runtime/php/<name>/conf/php.ini，容器内为/usr/local/etc/php/php.ini。使用docker exec时若引用宿主机路径会报“文件不存在”，因容器进程无法访问宿主机文件系统。正确做法是：配置修改在宿主机进行，重启容器生效；验证时用容器内路径或docker inspect查看挂载映射。关键原则：路径前缀决定执行侧——/opt/1panel/属宿
2026-10-04 07:32:34
810
原创 grep -n 行号辨换行
排查 PHP-FPM 配置时，发现 pm.status_path 与 slowlog 似在同一行，疑为语法错误。通过 grep -n 检查行号，二者分别位于第13、14行，确认为两行独立配置。进一步用 sed -n '13p;14p' 提取原文，cat -A 查看换行符，确认文件格式正确。粘贴显示的“合并”现象源于终端或复制过程中的换行丢失。最终结论：配置无误，无需修改。关键在于依赖工具元信息而非肉眼排版，四步法（行号判断、精确提取、换行检测、行为验证）可高效定位真实问题。
2026-10-03 07:36:39
574
原创 PHP 扩展加载失败
PHP php -m 报错“Unable to load dynamic library”时，核心问题常在括号内的依赖缺失（如 libzip.so.5: not found）。扩展 .so 文件存在不代表可加载，需用 ldd 检查其共享库依赖。通过 php -r 'echo ini_get("extension_dir");' 获取正确路径，再批量扫描所有 .so 文件的缺失依赖。关键点：依赖库名与包名不完全对应，尤其 Debian t64 过渡后包名变更（如 libpng16-16t64），排查脚本应兼容
2026-10-02 06:49:11
517
原创 服务器回显里的四个假故障
装包时出现 debconf 降级提示、26 个包未升级、.so 报错及 host-cache-size=0 均为正常现象。debconf 多次失败因无 TTY 和 TERM 环境，最终降级至 Noninteractive，不影响安装；26 not upgraded 表示仅安装了 unzip，其余包未主动升级，属预期行为；.so 报错中仅 memcached.so 显式带后缀，建议统一配置写法；host-cache-size=0 可正常运行，非问题。四者均在正确操作中出现，无需干预，避免误判浪费时间。
2026-10-01 07:00:17
455
原创 apt-get 补的库，一次重建全没了
容器重建导致 apt-get 补装的扩展依赖丢失，因补丁仅存于可写层。通过 php -r 'echo ini_get("extension_dir")' 动态获取扩展路径，结合 ldd 遍历检测缺失库，用 for 循环自适应包名变更（如 libpng16-16t64），实现跨版本复现。关键在于：补装不进镜像，重建即丢；验收靠脚本遍历，而非记忆清单。
2026-09-30 06:08:32
425
原创 MySQL 8.4 装完先改这一个参数
MySQL 8.4 默认将 innodb_flush_method 改为 O_DIRECT，绕过操作系统页缓存，但 innodb_buffer_pool_size 仍为 128MB，导致共用服务器上读性能下降。因缓存兜底层消失而新缓存未建，性能反不如 8.0。解决方案：手动设置 innodb_buffer_pool_size = 2G（4核8G共用环境），确保热数据在 buffer pool 内。验证通过 SHOW VARIABLES 及监控读请求与磁盘读比例。唯一需改参数，其余默认值可保留。
2026-09-29 09:23:58
757
原创 opcache 的三个假象
看似 opcache 未加载的三大迹象——php.ini 注释、CLI 显示 Disabled、php -m 出现两次——实为误读。真相是：opcache 通过 conf.d 机制正常加载，CLI 的 Disabled 仅因 opcache.enable_cli=0，而模块本身在 FPM 中已启用。验证应以 Web 探针为准，opcache_get_status() 才能真实反映缓存状态。
2026-09-28 05:05:23
690
原创 1Panel 部署 ThinkPHP8 踩坑实录
1Panel PHP扩展面板显示“已启用”不可信，实际容器中扩展因缺失依赖库而加载失败。通过php -m与ldd验证发现，gd、intl、zip、memcached等扩展虽勾选成功，但因libpng、libicu、libzip等共享库缺失，导致dlopen失败。面板仅校验配置项存在性，忽略运行时依赖，状态与真实加载结果脱钩。应以composer.lock中require段为准判断必需扩展，避免盲目安装冗余依赖。
2026-09-27 13:16:03
596
原创 上线前最容易漏的四个坑
前面五篇讲的是"跑不跑得起来"的坑——报错、崩、版本打架。今天这一篇（系列完结篇）讲另一类：代码全跑通、测试全通过、功能全正常，上线后却在真实用户嘴里翻车。
2026-09-26 17:40:56
549
原创 向量库跑通了，答案还是胡说？
1. 用户问"我皮肤干，还容易泛红，用什么好？"——检索只捞回保湿霜，漏了舒缓精华（**漏召回**）；2. 用户问"你们家有防晒霜吗？"——知识库里根本没有，模型却一本正经推荐了一款（**幻觉**）。
2026-09-26 05:37:05
669
原创 同一套 DeepSeek，三种框架六个坑
跑通一个框架，你会产生一种错觉："我会接大模型了。" 直到你拿同一把 DeepSeek key，换下一个框架，第一行就崩——而且每个框架崩得都不一样
2026-09-25 06:10:22
589
原创 【LLM 工程实践】Jev 决策模型原理：为什么 Agent 循环里 80% 的判断不该交给 LLM
Agent 循环里 80% 的调用只是判断题，用大模型回答等于用跑车送快递。本文拆解 Jev 决策模型的非自回归原理与校准置信度，附三段零依赖可运行代码，把「自动执行 / 慢模型复核 / 转人工」三档分流跑给你看。
2026-09-24 12:47:28
269
原创 环境与依赖篇：一个 venv 引发的血案
三连坑的完整因果链——为什么"建了环境"却全装进全局、为什么两个框架抢同一个依赖会打架、为什么你以为只有一条线会打架
2026-09-23 08:49:33
665
原创 18 天炸了 47 次，最值钱的 5 个坑
你有没有过这种时刻：脚本跑完、结果全对，终端却突然爆出一整屏红字。第一反应是代码写错了，查来查去，跟你写的代码一点关系都没有。
2026-09-22 06:24:27
503
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人