跳到主要内容

11 篇博文 含有标签「saas-development」

查看所有标签

Python 任务全标 failed 却不报错？try/except 吞掉了异常

· 阅读需 5 分钟
CCLEE
CCLEE

在 RAG 知识库项目中排查文档同步任务全部标记 failed 的静默故障，以下是完整排查过程。

TL;DR​

重构一个公共方法改了参数签名，但漏改了一个调用方。调用方按旧契约传参抛 TypeError，而这个调用被包在 try/except 里，异常被悄悄吞进 failed 计数——服务不崩溃、日志没有 ERROR，只有计数字段悄悄上涨。这类「静默故障」是最难查的 bug。两个解法：重构签名后 grep 所有调用方同步；except 块必须记日志或重抛，绝不静默吞掉。

Node.js ESM 动态 import 报模块找不到？检查文件扩展名

· 阅读需 4 分钟
CCLEE
CCLEE

在为客户构建 SaaS 数据分析平台时遇到此问题，记录根因与解法。

TL;DR​

Node.js ESM 模式下，import('./path/to/module') 不会自动解析 ./path/to/module.js。TypeScript 编译的 dist 产物如果遗漏 .js 后缀，模块加载时抛出 ERR_MODULE_NOT_FOUND。如果这个 import 在延迟逻辑中（如定时器、条件分支），应用启动正常但运行一段时间后崩溃，PM2 表现为重启计数飙升。

解法：确保所有 ESM 动态 import 路径包含 .js 扩展名，并在 build 流程中自动修复。

问题现象​

PM2 状态显示应用不断重启：

│ name             │ ↺    │ status │ uptime │
│ analytics-api    │ 9    │ online │ 28m    │

错误日志每几分钟重复：

Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/app/dist/domains/video/cleanup'
  imported from /app/dist/server.js

但文件实际存在：

$ ls dist/domains/video/
cleanup.js  executor.js  queue.js

根因​

ESM 不自动解析文件扩展名​

Node.js 的 CommonJS (require()) 会自动尝试 .js、.json 等后缀。ESM (import) 不会。

// ❌ ESM 模式下找不到模块
import('./domains/video/cleanup')
// Node.js 查找: ./domains/video/cleanup （精确路径，无扩展名）
// 实际文件:     ./domains/video/cleanup.js

// ✅ 必须带 .js 后缀
import('./domains/video/cleanup.js')

延迟 import 隐藏了问题​

这个 import 在定时器中延迟执行：

// server.ts — 启动时不立即执行
import('./domains/video/cleanup.js').then(({ startCleanupScheduler }) => {
  startCleanupScheduler(); // 几秒后才触发
});

应用启动成功（DB 连接、端口监听都正常），定时器触发时 import 报错 → 进程崩溃 → PM2 重启 → 再次启动成功 → 定时器再次触发 → 再次崩溃。形成崩溃循环。

为什么之前没问题？​

旧版本的 dist 产物是通过手动 build 生成的，build 脚本包含 .js 后缀修复步骤。某次部署时跳过了 build 后的修复步骤，直接用 tsc 输出的产物部署，tsc 不修改 import 路径。

解决方案​

1. TypeScript 源码中写 .js 后缀​

TypeScript 官方推荐：即使在 .ts 文件中，也写 .js 后缀：

// ✅ TypeScript 源码中也写 .js
import('./domains/video/cleanup.js').then(({ startCleanupScheduler }) => {
  startCleanupScheduler();
});

2. Build 后自动修复（推荐）​

在 build 流程中添加后缀修复脚本，自动为没有扩展名的 import 补上 .js：

{
  "scripts": {
    "build": "tsc && node fix-imports.js"
  }
}

fix-imports.js 核心逻辑：

import { readFileSync, writeFileSync, readdirSync } from 'fs';
import { join } from 'path';

function fixImports(dir) {
  for (const file of readdirSync(dir, { withFileTypes: true })) {
    const fullPath = join(dir, file.name);
    if (file.isDirectory()) {
      fixImports(fullPath);
    } else if (file.name.endsWith('.js')) {
      let content = readFileSync(fullPath, 'utf8');
      // 修复动态 import: from 'xxx' → from 'xxx.js'
      const fixed = content.replace(
        /import\(['"](\.[^'"]+)['"]\)/g,
        (match, path) => path.endsWith('.js') ? match : match.replace(path, path + '.js')
      );
      // 修复静态 import: from 'xxx' → from 'xxx.js'
      const fixed2 = fixed.replace(
        /from\s+['"](\.[^'"]+)['"]/g,
        (match, path) => path.endsWith('.js') ? match : match.replace(path, path + '.js')
      );
      if (fixed2 !== content) {
        writeFileSync(fullPath, fixed2);
      }
    }
  }
}

build 流程自动为所有相对路径 import 补全 .js 后缀，TypeScript 源码保持无后缀写法，ESM 部署不再出现模块找不到的错误。

注意事项

  • 此问题只在 Node.js ESM 模式（"type": "module" 或 .mjs 文件）下出现，CommonJS 不受影响
  • 静态 import（import ... from './foo'）同样受此限制，不仅限于动态 import()；ESM 的 import 提升还会导致另一个常见问题——dotenv 在 import 链之后才执行，环境变量读不到
  • 使用 tsx、ts-node 开发时不报错（它们会自动解析后缀），但 node dist/server.js 生产运行时出错
  • PM2 崩溃循环的典型特征：重启计数（↺）持续增长，每次 uptime 不超过几分钟
联系合作

用 Tavily MCP 替代智谱搜索，节省 70% 编码套餐额度

· 阅读需 4 分钟
CCLEE
CCLEE

在使用 智谱 GLM 编码套餐 进行日常开发时，发现一个容易被忽视的额度消耗问题：智谱内置的 MCP 联网搜索和网页读取工具，每次调用都消耗编码套餐额度。本文记录排查过程和用 Tavily MCP 替代的方案。

TL;DR​

智谱 GLM 编码套餐内置 web-search-prime 和 web-reader 两个 MCP 服务，每次搜索/读取消耗对话额度。替换为 Tavily MCP 后，联网搜索使用独立免费额度（1000 次/月），不再挤占编码对话用量。

用 Python FastMCP 搭建自定义 MCP 工具库，按需接入任意 AI 模型

· 阅读需 8 分钟
CCLEE
CCLEE

在为客户构建 AI Agent 系统时，我们发现不同任务对模型能力和成本的需求差异很大：图像分析用视觉模型、文本补全用轻量模型、内部数据查询用本地模型。MCP（Model Context Protocol）让每个能力变成独立的工具，AI 客户端按需调用。

TL;DR​

用 Python FastMCP 30 分钟搭建自定义 MCP Server，按场景和成本接入任意 OpenAI 兼容 API。本文以豆包视觉模型为例演示完整流程，并提供文本生成、图像生成、语音合成等场景的扩展模板。

绕过 Supabase Auth 实现 Playwright E2E 测试免登录

· 阅读需 4 分钟
CCLEE
CCLEE

在为客户构建 AI Agent SaaS 平台时遇到此问题，记录根因与解法。

TL;DR​

E2E 测试不应该依赖真实的 OAuth 登录流程。通过在 useAuth hook 中检测 localStorage 的测试标记，直接注入 mock 认证状态，跳过 Supabase 初始化。同时将 Zustand store 的 loading 默认值改为 false，避免 AuthGuard 卡在无限 spinner。