JACIN Blog
专注 AI 应用开发、Python 后端与工程实践，持续记录大模型落地、工具构建与真实项目经验。
“AI见闻”可被定位为收纳人工智能相关观察、资讯线索、趋势讨论与零散认知记录的类别，用于承接那些不适合归入具体教程、工程实践或系统性技术分析的内容。该类别的核心价值在于提供一个判断入口：当文章重点是对 AI 领域现象、产品变化、行业动态或个人阅读所得的整理，而不是给出可复现的实现步骤时，可以考虑放入此处。它需要与更明确的技术分类保持边界，例如模型部署、提示词工程、应用开发或问题排查类内容，若正文已经有清晰的操作对象和技术路径，应优先归入对应专业类别。适合收纳的话题包括 AI 工具体验、技术新闻解读、研究或产品见闻、生态变化记录，以及尚未形成完整方法论的思考。使用该类别时应关注分类必要性，避免把所有与 AI 有关的内容都笼统放入其中；如果某类主题持续积累并形成稳定方向，也可以进一步拆分为子类别或合并到已有分类中。
这则笔记记录了在 Docker 容器中直接维护 PostgreSQL 的两个常用操作：创建数据库和调整最大连接数。创建数据库部分使用 docker exec 进入正在运行的 my-postgres 容器，并通过 psql 指定用户、目标库和 -c 参数执行 CREATE DATABASE demo_db_for_gin，其中示例里的 super_postgres 需要替换成实际 PostgreSQL 用户名。连接数配置部分面向 docker-compose 场景，通过在服务配置中加入 command: postgres -c max_connections=1000，将 PostgreSQL 默认的 100 个连接提升到 1000。配置值并非固定推荐，需要结合机器资源和业务并发情况调整，避免只提高参数而忽略内存与连接管理成本。修改后可再次使用 docker exec 调用 psql，并执行 SHOW max_connections; 验证容器内 PostgreSQL 是否按预期加载新参数。整体适合作为容器化 PostgreSQL 日常初始化、临时建库和连接数参数核验的速查记录，尤其适合已经具备 Docker 与 psql 基础用法的开发或运维人员。
这份笔记围绕 Nginx 多站点配置的模块化管理展开，核心做法是用软链接把“已编写的配置”和“当前生效的配置”分离。正文将 /etc/nginx/sites-available/ 定位为配置仓库，用来保存所有 server 文件、草稿、备份或暂时下线的网站；将 /etc/nginx/sites-enabled/ 作为实际加载目录，只放指向仓库文件的软链接，并通过 nginx.conf 在 http 段 include 该目录来决定哪些站点生效。文章给出了一份基础 nginx.conf 示例，包含事件连接数、日志、gzip、Keep-Alive、SSL 全局参数，以及同时加载 conf.d 和 sites-enabled 的关键配置。随后以一个 HTTPS 探针站点为例，展示 server 块如何配置证书、server_name、反向代理到 localhost:25774，并补充真实 IP、转发协议、WebSocket Upgrade、关闭代理缓冲和 50M 上传限制等常见代理设置。启用流程则被简化为脚本：使用 ln -sf 将 sites-available 下的配置批量链接到 sites-enabled，再执行 nginx -t 校验，通过后 reload 服务。它适合小型服务器或个人多站点环境，用较低成本实现站点配置的归档、迁移、批量启用和下线控制；需要注意的是，真正被 Nginx 读取的是 include 的 enabled 目录，单独把文件放进 available 并不会生效。
这篇笔记围绕 Nginx 在反向代理和 Cloudflare 接入场景下的访问控制配置展开，核心问题是如何在使用真实客户端 IP 的同时避免错误信任可伪造的请求头。文中先给出一种粗糙写法：在 server 中将 set_real_ip_from 设为 0.0.0.0/0，并通过 real_ip_header CF-Connecting-IP 改写 remote_addr，再配合 allow 与 deny all 做访问限制；但这种做法等于让任意来源都能提交 CF-Connecting-IP，攻击者可借此伪造来源地址。文章解释了 Nginx 默认情况下 remote_addr 代表 TCP 连接源 IP，未启用 real_ip 时相对可信，而一旦信任范围放得过宽，就会主动放弃这一安全边界。更稳妥的方案是从 Cloudflare 官方 IPv4、IPv6 地址接口拉取网段，生成 cloudflare_real_ip.conf，逐行写入 set_real_ip_from，并配置 real_ip_header 与 real_ip_recursive。随后可在 http 块全局 include，或在单个 server 块中按站点生效，更新脚本执行后通过 nginx -t 校验并 reload 服务。文中还提醒 allow 规则按顺序匹配，deny all 会直接拒绝并返回 403；如果 VPS 同时具备 IPv4 和 IPv6，放行列表也要同时覆盖两类地址。最后通过 crontab 每周自动刷新 Cloudflare 网段，适合需要在 Nginx、Cloudflare 和反向代理链路中正确处理真实 IP 与访问白名单的运维或后端开发者参考。
这篇笔记聚焦 Docker 私有镜像仓库的 hosted/private 托管模式，说明它不是自动代理上游的缓存，而是需要用户或 CI/CD 主动把镜像搬运进去后才能供其他机器拉取。文章用 nginx:latest 迁移到 hub.jacin.me/library/nginx:latest 为例，给出 pull、tag、push 三步流程：先从 Docker Hub 拉取镜像，再改成本地私有仓库命名空间，最后推送到自建仓库。推送时出现 only the available single-platform image was pushed 的提示，是因为官方 nginx:latest 属于多架构镜像，但普通 docker pull 通常只下载当前机器 CPU 架构对应的版本，push 时私有仓库也只能保存本地已有的平台内容。对服务器、开发机和生产环境都统一使用 amd64 等同构场景来说，这通常不影响运行；但如果 amd64 VPS 推送后的镜像被 arm64 的 Mac M1/M2 或树莓派拉取，就可能遇到架构不匹配、exec format error 或找不到匹配架构的问题。文末通过表格区分代理模式和私有仓库模式：前者偏向 Docker Hub 等上游的加速与只读缓存，后者用于存储和分发自己构建的业务镜像，并且必须依赖 push 写入内容。它适合正在搭建内网镜像分发、理解多架构镜像行为，或在代理缓存与私有托管之间做选型的运维和后端开发者阅读。
服务器与部署这篇部署记录聚焦在自建私有 Docker Registry 的最小可用方案，将 registry:2 与 joxit/docker-registry-ui 通过 docker-compose 组合到同一个外部网络中运行，并把 Registry 数据持久化到本地目录。配置上的关键点是 Registry 只监听宿主机 127.0.0.1:5000，避免直接暴露服务，同时启用 REGISTRY_STORAGE_DELETE_ENABLED 以支持镜像删除；UI 则监听 127.0.0.1:18080，通过 NGINX_PROXY_PASS_URL=http://registry:5000 走容器内网代理，因此 Registry 侧不需要额外配置 CORS。外层 Nginx 分成两个 HTTPS 站点：一个面向 hub-ui.jacin.me 代理管理界面，一个面向 hub.jacin.me 代理仓库 API，并统一配置 Cloudflare 真实 IP、基础认证、转发头、长超时和 TLS 证书。仓库域名的 Nginx 配置额外设置 client_max_body_size 0，用于避免推送较大镜像层时被请求体大小限制拦截。验证部分使用一个基于 alpine:latest 的简单 Dockerfile 构建测试镜像，按 hub.jacin.me/test-project/hello-world:v1 的命名规则打标签，再通过 docker login 与 docker push 检查私有源是否可写。适合需要在个人服务器或小团队环境中快速搭建带 Web UI、HTTPS 入口、密码保护和删除能力的私有 Docker 镜像仓库的运维与后端开发者参考。
常规该页面的正文内容只包含一张通过 Markdown 嵌入的图片，图片地址来自站点 CDN，并标注了 670×500 的显示尺寸。除图片资源本身外，正文没有提供文字说明、操作背景、测试目标、截图内容解读或任何可验证的技术结论，因此无法判断它是在测试图片上传、页面渲染、媒体展示，还是记录某个功能状态。现有信息只能确认页面具备展示单张图片的用途，不能支持读者提炼出教程步骤、配置方法、问题原因或观点判断。对于搜索、RSS 或文章卡片读者来说，这类内容的阅读价值主要停留在“查看图片是否能正常呈现”这一层面。若要形成更明确的技术导读，需要补充图片所表达的对象、测试场景、预期结果，以及与标题中“测试功能”相关的说明。当前摘要因此应保留边界感，避免把图片内容或作者意图解释成正文没有写出的信息。
这份笔记聚焦 VPS 基础测试中的两个常用场景：运行 NodeQuality（nq）做机器质量检测，以及用 curl 粗略观察访问链路耗时。由于 nq 测试相对吃内存，命令示例选择放到 nohup 后台执行，并把标准输出和错误输出统一写入 nq.log，避免 SSH 断开或终端关闭导致任务中断。文中给出两种交互输入处理方式：一种用 yes 持续自动确认，适合全部按确认推进；另一种先 echo y 确认启动，再用 yes n 对后续选项默认拒绝，便于减少不必要的交互选择。测速部分使用 curl -w 输出 DNS 解析、TCP 连接、TLS 握手、首包时间和总耗时，并通过 -o /dev/null 与 -s 去掉页面内容和进度信息，使结果更适合快速查看网络阶段耗时。它更像一份面向 VPS 初步体检的命令备忘，适合需要临时评估服务器质量、后台跑测试脚本或排查基础访问延迟的运维和个人站点维护者使用。需要注意的是，笔记只给出命令用法和日志落盘方式，并未展开解释 NodeQuality 各项评分含义或 curl 时间指标的进一步诊断边界。
Python 开发从 PyCharm 迁移到 Cursor 调试 Python 项目时，最容易遇到的问题是模块导入路径不再由 IDE 自动补齐，导致运行当前文件时出现 ModuleNotFoundError。文章给出的常规做法是在项目下创建 .vscode/launch.json，配置 Python launch 任务，并通过 env 中的 PYTHONPATH: ${workspaceFolder} 手动把工作区加入模块搜索路径，相当于复刻 PyCharm 的 Mark Directory as Sources Root。它也解释了 Python 默认只会搜索标准库、site-packages 和当前脚本目录，因此在 VS Code/Cursor 这类编辑器中需要显式声明项目根路径。针对 conda 环境，文章进一步给出 settings.json 中固定 python.defaultInterpreterPath，以及 launch.json 中指定 python 解释器路径、保留 PYTHONPATH、设置 PYTHONUNBUFFERED=1 的配置方式，以便调试控制台正常输出日志。需要注意的是，Python Environment Manager 等环境管理插件可能在选择环境时自动重写 settings.json，与 launch.json 中的解释器配置冲突，并引发 permission denied，因此作者建议删除相关插件。整体适合正在从 PyCharm 转向 Cursor、希望降低内存占用但仍保留 Python 单文件调试和 conda 环境调试能力的开发者参考。
开发工具这篇记录围绕 OrbStack 的 Linux Machine 模式，说明如何在 macOS 上快速创建一个轻量级 Ubuntu 隔离环境，用于临时测试、运行脚本或准备不同架构的 Linux 用户态。正文给出的核心流程很直接：通过 brew 安装 OrbStack，使用 `orb create ubuntu guardian-test` 创建机器，再用 `orb -m guardian-test` 进入；如果需要 x86/amd64 环境，则用 `orb create -a amd64 ubuntu guardian-x86` 单独创建。文章强调 OrbStack 相比 Docker Desktop、Multipass 的优势在于基于 macOS 原生轻量级虚拟化框架，空闲内存、启动速度和 CPU 占用都更适合日常开发中的短时隔离需求。需要特别注意的是，OrbStack 默认开启文件系统共享，Linux 内的 `/mnt/mac`、`/Users`、`/Volumes` 等路径可能直接映射到 Mac 真实文件，未知脚本若删除这些目录下的内容，会影响宿主机数据。为降低风险，作者建议高风险脚本只在 `/root` 或 `/home/linux_user` 等 Linux 内部目录运行，并提供了手动卸载共享挂载点以及写入 `/etc/rc.local` 实现开机自动卸载的命令。最后还补充了分流规则配置中的网络模式注意点：不能使用 fake-ip，需要切换到 host 模式，否则规则里看到的可能都是内网 IP。
Python 开发这篇笔记聚焦 FastAPI 中使用 ORJSONResponse 提升 JSON 响应序列化性能的原因与配置方式，核心场景是接口返回大列表、大 JSON 或包含时间字段等复杂类型的数据库记录。正文将默认 JSONResponse/标准库 json 与 orjson 的路径拆开比较：前者通常先把 Python 对象转换成 Python str，再由 Web 层编码成 UTF-8 bytes；orjson 则直接生成可网络传输的 UTF-8 字节，减少一次全量内存拷贝和编码转换。文章还解释了 orjson 采用 Rust 实现、面向速度优化并利用 SIMD 的背景，以及它对 datetime、UUID、numpy、dataclasses 等类型的原生支持如何避免频繁回调 Python 函数，从而降低额外开销和 GIL 争用。实践部分给出安装 orjson、导入 ORJSONResponse，并通过 FastAPI(default_response_class=ORJSONResponse) 设置全局默认响应类的示例。性能判断上，文中认为纯序列化微基准可能达到标准库的 5 到 10 倍，但在真实 Web 接口里收益取决于响应体大小和瓶颈位置。对于只返回极小 JSON 的接口，网络 IO 可能掩盖差异；而返回几千行记录、数 MB JSON 或大量 datetime 字段时，ORJSONResponse 更可能带来可感知的响应时间下降。
这篇解释围绕“洛杉矶同城机房为什么能测到约 1ms Ping”展开，把低延迟拆成物理距离、互联枢纽和链路形态三个层面。正文先用光在光纤中约 20 万公里/秒、Ping 是往返时间来估算：1ms 足够覆盖约 100 公里往返，而洛杉矶核心区域之间的实际光纤传播耗时通常只占 0.1ms 到 0.3ms，剩余时间主要来自路由器处理和排队。随后文章指出，洛杉矶的很多 IDC、运营商和海底光缆接入点会汇聚到 One Wilshire 这类西海岸重要网络枢纽，所谓不同“洛杉矶机房”在网络层面可能只是隔着几层楼或几条街。它还进一步区分了 IDC 之间的暗光纤、内网直连与普通公网绕行的差异，说明低延迟并不只取决于地图上的城市大小，而取决于实际走线和交换位置。文章最后用家庭宽带访问 IDC 作对照，提到 BRAS、计费、鉴权、NAT 等运营商环节会引入额外路径和处理成本。适合网络学习者、VPS 用户和运维人员理解同城机房延迟测试结果，避免把“洛杉矶很大”直接等同于“网络一定很远”。
