WordPress中存储与访问数据实现商品限购的最佳方案

绝对禁止在客户端JavaScript中写入任何数据库访问凭证，这是高危安全漏洞，任意访问者都可以通过浏览器开发者工具扒取凭证，篡改计数、拖库甚至删除站点数据。你提到的REST API实现思路是可行的，但需要配合WordPress原生能力做权限和逻辑校验，不需要自建数据库表，也不会泄露敏感信息，具体实现如下：

核心设计原则 #

所有计数读写的核心逻辑必须放在WordPress服务端执行，前端仅承担状态展示、按钮控制的只读逻辑，计数递减的触发源只能是支付平台的服务端支付成功回调，绝对不能把计数修改权限开放给前端。

具体实现步骤 #

• 限购值存储：直接使用WordPress自带的options表存储全局限购值即可，通过内置的get_option()、update_option()函数读写，不需要额外建表维护，自带原子操作能力，维护成本远低于自定义数据表或者本地JSON文件。
• 接口注册：在主题functions.php文件或者自定义简易插件中注册两个REST API接口：
  1. 公开状态查询接口：无权限校验，供前端页面拉取当前剩余库存状态，参考代码：

add_action('rest_api_init', function () {
    register_rest_route('stock-limit/v1', '/status', [
        'methods' => 'GET',
        'callback' => function () {
            // 初始化限购值，首次调用自动写入预设的限购总数X
            if (!get_option('product_a_total_limit')) {
                add_option('product_a_total_limit', X, '', 'no'); // 把X替换为你要设置的限购总数
            }
            $remaining = (int)get_option('product_a_total_limit');
            return [
                'remaining' => $remaining,
                'sold_out' => $remaining <= 0
            ];
        },
        'permission_callback' => '__return_true'
    ]);
});

2. 库存扣减接口：不对前端开放，加严格校验规则：仅允许支付平台官方IP段访问、必须校验支付回调的签名参数，确认请求是支付平台发起的真实有效支付成功通知时，才执行库存扣减逻辑，扣减前先判断剩余库存是否大于0，避免超卖。

• 支付回调配置：在你使用的支付系统后台，配置支付成功Webhook地址为上述库存扣减接口的路径，每产生一笔真实完成支付的订单，支付平台会自动向该地址发起请求，服务端校验通过后将限购值减1，当数值减到0时自动标记售罄状态。
• LeadPages前端适配：在放置商品A购买按钮的页面插入小段JS代码，页面加载时调用公开的状态查询接口，如果返回售罄标记，直接禁用购买按钮、替换为售罄文案，参考代码：

fetch('/wp-json/stock-limit/v1/status')
.then(res => res.json())
.then(res => {
    const buyButton = document.querySelector('替换为你购买按钮的CSS选择器');
    if (res.sold_out) {
        buyButton.disabled = true;
        buyButton.innerText = '已售罄';
    }
})

避坑说明 #

• 不要使用本地JSON文件存储计数：文件存储没有并发锁机制，多笔订单同时回调时会出现超卖问题，若文件权限配置不当还可能被任意下载、篡改，安全性和稳定性都远低于WordPress原生options存储。
• 不要在前端点击购买按钮时触发库存扣减：前端请求可以被任意伪造，未支付的用户也能恶意扣减库存，必须以服务端收到的、校验通过的支付成功回调作为唯一扣减依据。
• 扣减库存时必须做前置判断：执行扣减操作前先校验当前剩余库存是否大于0，避免并发场景下库存扣成负数，出现超卖。

内容的提问来源于stack exchange，提问作者Code Tinkerer