他登录后就生效了呀，不会丢失

多次新注册用户测试，只有在登录之后才会收到兑入积分， 似乎是只有登录之后才开通该站账号 （注册时只首次成功登录注册站点，同步登录其它站点只在以后登录退出时生效）！

操作 积分变更 详情 变更时间
UCenter积分兑换支出 铜板 -300 通过UCenter兑换积分 2023-01-05 19:06
UCenter积分兑换支出 铜板 -900 通过UCenter兑换积分 2023-01-05 19:04
UCenter积分兑换支出 铜板 -100 通过UCenter兑换积分 2023-01-05 19:04

以上是新用户兑出积分记录，以下是登陆过兑入站点正常接收积分，显示只有登录后才成功接收兑入积分：

操作 积分变更 详情 变更时间
UCenter积分兑换支出 蜜枣 +30 通过UCenter兑换积分 2023-01-05 19:06

这个是正常流程，因为积分结算就是登录时计算结算并更新用户组等信息的

新用户刚在A站注册且还没有登陆过B站，此时通过uc向B站兑换积分将导致积分永久丢失，例如上例的以下两项积分用户将永久接收不到，包括以后重新登录B站也接收不到（原因大概是在登录B站前B站还没有该用户账号）：

UCenter积分兑换支出 铜板 -900 通过UCenter兑换积分 2023-01-05 19:04
UCenter积分兑换支出 铜板 -100 通过UCenter兑换积分 2023-01-05 19:04

19:05 用户成功登陆B站，此后的所有兑入积分才正常收到。

我记得之前讨论过uc没有实现返回失败的问题，估计跟这个有关

是的，现在就这么设计的...... 我也感觉很坑。

刚看了下，这个位置好像直接返回API_RETURN_FAILED应该就行……
之前我们讨论过的uc端没有实现的是API_RETURN_FORBIDDEN，跟这个事情应该没有关系。

你看一下上面那张图（应该位于api/uc.php里面），里面有个API_RETURN_SUCCEED（注意是光标指的那个，不要改另一个），你直接给它换成API_RETURN_FAILED，再试试看

		$uid = $get['uid'];
		if(!getuserbyuid($uid)) {
			return API_RETURN_FAILED;
		}

还是扣积分提示成功，登录查看没收到积分。而成功登录之后可正常收到兑换积分。

你看看uc通知列表里是否有失败记录，点击重发以后能不能收到，如果这个可以的话那基本也就能做到这了。

主要是uc这东西它是站点和uc之间通信这么一种机制，站点把兑换积分的请求发给uc就结束了，uc再把兑换积分的请求发给对方站点就结束了，这么一种简易的流程。

但如果想要实现你所说的判断账号是否存在，就意味着流程变成了站点问uc，uc问对方站点，对方站点告诉uc账号存在，（如果存在）uc告诉站点存在，站点扣除积分并发给uc，uc收到积分发给对方站点，对方站点收到积分加上。这么复杂的流程在现有的uc通信机制下是实现不了的。

额，你再仔细看看我上面说的逻辑……
返回失败的时候已经不可能不扣积分了，积分已经从站点扣除发到uc那了，就算失败最多也只能暂存在uc等待重试（这个还不一定能保证实现），不可能不扣除了，因为扣除行为早在那之前就已经完成了。

要想判断，得走我上面说的那一大串超级复杂的逻辑，目前是实现不了的。

或者可以这么说，这个积分跨站兑换是一个非常简易的机制，建立在一个非常脆弱的传输通道上，可靠性可以说是没有任何保障可言的。即便排除对方账户没激活这种因素，普通的网络故障，请求丢失甚至是服务器波动等都可以轻松的破坏这个兑换机制。所以如果需要可靠的积分兑换机制（不能容忍错误），还是建议采取别的方式实现，这个兑换机制再怎么优化都不可能可靠了，它原理摆在这……

明白了！

简单说就是站点扔给uc，uc扔给对方站点，这个扔的过程是 简易的走api发了就完事的，没有回执，没有校验，那扔的时候无论因为任何原因丢了，还是对方拒收了，或者是处理失败了，那就是没有了。

假设是处理财务级别的，那真没人敢这么干，那必须是每笔交易生成订单记录，从发起交易到交易结束全流程记录状态，拿到对方成功处理计入账户的回执以后才能结单的，中间有任何异常还需要支持状态回滚，哪怕这个过程对用户不可见，步骤也一点都不能少。这才能保证两边的数据永远对的上。

很早以前兑换一次常会收到多笔，现在还比较稳定平时没有发现其它问题，稳妥起见还是放弃使用这一功能，倒是可以使用充值功能替代，但是积分的通用性就不强了，用户也会多些麻烦。待到将来有条件的话，再严密二开。