前端（SvelteKit）与后端（Django）优惠逻辑复用方案咨询

1. WebAssembly(Wasm)跨端复用方案 #

这是最彻底的跨端代码复用方案，核心逻辑只写一次，编译为Wasm后同时支持前端TS和后端Python调用。

• 实现步骤：

  • 用纯TypeScript/JavaScript编写优惠计算逻辑（避免依赖浏览器或Node.js特定API）；
  • 使用AssemblyScript（TS转Wasm）或esbuild编译生成Wasm模块；
  • 前端SvelteKit：直接在客户端导入Wasm模块，调用其中的函数完成本地实时计算；
  • 后端Django：通过Python的Wasm运行时库（如wasmtime-py、pywasm）加载Wasm模块，执行优惠逻辑验证。

• 优缺点：

  • ✅ 完全复用核心代码，前后端计算逻辑100%一致；
  • ✅ 前端本地运行无网络请求，体验流畅；
  • ❌ 存在一定学习成本，复杂逻辑的调试工具链不如原生TS/Python成熟；
  • ❌ 若逻辑依赖特定语言API（如Python的数据库操作、TS的DOM API），需要做适配封装。

2. 独立NPM包+Python JS运行时调用 #

将优惠逻辑封装为无环境依赖的TS/JS模块，发布为独立NPM包，前端直接导入，后端通过Python调用JS运行时执行该模块。

• 实现步骤：

  • 编写纯TS优惠逻辑，打包为UMD/ES模块（确保无浏览器/Node依赖）；
  • 前端SvelteKit：直接import这个NPM包，客户端本地计算；
  • 后端Django：
    • 方式一：用node-api编写Python扩展，直接调用JS模块；
    • 方式二：通过Python的subprocess调用Node.js脚本，传入计算参数并获取结果；
    • 方式三：使用Python的JS运行时库（如dukpy、PyV8）直接加载执行JS模块。

• 优缺点：

  • ✅ 用熟悉的TS编写逻辑，无需学习Wasm；
  • ✅ 前端本地计算无请求，体验好；
  • ❌ Python调用JS存在一定性能开销，高并发场景需评估；
  • ❌ 部署时需要维护Node.js环境（若用subprocess方式），增加部署复杂度。

3. SvelteKit共享逻辑层+后端RPC调用 #

将优惠逻辑放在SvelteKit的共享库目录（src/lib），前端本地调用，后端通过RPC或HTTP请求复用同一逻辑。

• 实现步骤：

  • 在src/lib/discounts.ts中编写纯TS优惠计算函数（无环境依赖）；
  • 前端SvelteKit：直接import这些函数，客户端实时计算；
  • 后端Django：
    • 方式一：调用SvelteKit的API端点（如/api/calculate-discount），该端点内部调用src/lib中的函数；
    • 方式二：用tRPC建立Django与SvelteKit的RPC通信，直接调用共享函数。

• 优缺点：

  • ✅ 逻辑只写一次，维护成本低；
  • ✅ 前端本地计算无请求，体验流畅；
  • ❌ 后端依赖SvelteKit服务的可用性，部署时需保证SvelteKit服务稳定；
  • ❌ 相比Wasm或本地JS运行时，多了一次网络调用（若用HTTP端点）。

关于SvelteKit Actions的说明 #

SvelteKit Actions是运行在服务器端的函数，前端调用Actions仍需发送HTTP请求，无法实现“前端本地实时计算”的需求，因此不符合你的场景。

内容的提问来源于stack exchange，提问作者Kevin Renskers