如何正确配置 PayPal SDK 的 fetch 请求路径

本文详解为何无法将 PayPal fetch 请求路径直接设为服务器本地文件路径（如 /home/checkfetch.php），并指导开发者通过合法 Web 路径实现安全、可访问的后端接口调用。

本文详解为何无法将 paypal `fetch` 请求路径直接设为服务器本地文件路径（如 `/home/checkfetch.php`），并指导开发者通过合法 web 路径实现安全、可访问的后端接口调用。

在集成 PayPal JavaScript SDK 时，许多开发者会误将 fetch() 的目标 URL 写成服务器上的绝对文件系统路径（例如 /home/mysite/checkfetch.php 或 /home/checkfetch.php），期望前端 JavaScript 直接“读取”该 PHP 文件。但这是根本行不通的—— 浏览器中的 fetch() 发起的是 HTTP 请求，而非文件系统读取操作 。它只能访问可通过 Web 服务器公开路由访问的 URL（即用户能在浏览器地址栏中输入并成功加载的地址），而绝非服务器内部的任意磁盘路径。

✅ 正确做法：使用 Web 可达的相对或绝对 URL

假设你的网站域名为 https://example.com，且实际 Web 根目录（DocumentRoot）指向 /home/mysite/public_html，那么：

• ✅ 合法路径示例（可通过浏览器访问）：

  • /checkfetch.php → 对应服务器文件 /home/mysite/public_html/checkfetch.php
  • /api/order.php → 对应 /home/mysite/public_html/api/order.php
  • https://example.com/checkfetch.php

• ❌ 非法路径示例（浏览器无法解析，fetch 必然失败）：

  • /home/checkfetch.php（无 Web 服务映射，404）
  • /home/mysite/public_html/checkfetch.php（虽是真实路径，但未暴露为 Web 路由，仍 404）
  • file:///home/mysite/checkfetch.php（浏览器禁止跨源 file:// 协议请求）

因此，你原代码中：

return fetch('/home/mysite/public_html/checkfetch.php', { method: 'post'})

之所以“看似工作”，极可能是因为 Web 服务器（如 Apache）被异常配置为将 /home/mysite/public_html/ 映射到了某个可访问路径（例如通过别名 Alias），但这属于危险且不可移植的配置， 严重违背 Web 安全与部署规范 。

✅ 推荐实践：标准化部署 + 明确路由设计

1. 将后端脚本置于 Web 根目录下合理子路径
   例如，把 checkfetch.php 放入 /home/mysite/public_html/api/ 目录，并确保其可通过 https://example.com/api/checkfetch.php 访问。

2. 在 PayPal 按钮中使用标准 Web 路径

   createOrder: function(data, actions) {return fetch('/api/checkfetch.php', {  // ← 纯路径，由当前域名自动补全协议 + 主机         method: 'POST',         headers: { 'Content-Type': 'application/json'}     })     .then(response => response.json())     .then(orderData => orderData.id); }

3. （可选）启用 CORS（若跨域）
   若后端与前端域名不同（如 API 托管在 api.example.com），需在 checkfetch.php 响应头中添加：

   <?php header('Access-Control-Allow-Origin: https://example.com'); header('Access-Control-Allow-Methods: POST'); header('Access-Control-Allow-Headers: Content-Type'); // …… 其余逻辑 ?>

⚠️ 关键注意事项

• public_html 是典型共享主机的 Web 根目录标识， 不应出现在 URL 路径中 ；它只是服务器文件结构概念，对客户端完全透明。
• 永远不要在前端暴露敏感文件系统路径——这属于信息泄露风险。
• 开发前务必确认 Web 服务器的 DocumentRoot 和 URL 路由规则（如 Apache 的 <Directory>、Nginx 的 location 块）。
• 使用浏览器开发者工具的 Network 面板验证请求是否返回 200 OK 及有效 JSON，避免静默失败。

遵循 Web 架构基本原理： 前端只与 Web 服务器对话，Web 服务器再与文件系统交互 。理清这一分层，即可彻底规避路径配置陷阱，构建健壮、可维护的支付集成方案。