@brader 如果访问量不大，正常的锁就 ok 了
如果访问量大，这个设置也会出问题，还是得加锁(数据库锁或队列锁)

所以这个没有什么意义

对。。忽略了，如楼上所说，你这个还不如事务锁，因为不但阻塞了，还仍然存在超卖问题

我觉得超卖的主要问题不是卖超了，而是高并发下仍然保证能流畅且不出错的运行，你这个也是基于数据库锁来阻塞请求，跟人人都会用的基本的事务锁没有本质区别，解决不了高并发的问题

@musi 确实又绕过了。。又升级了下，再看看呢

```
```
function isNative(api) {
if (XMLHttpRequest.hasOwnProperty('toString')) return false;
if (typeof XMLHttpRequest != 'function') return false;
if (typeof XMLHttpRequest.valueOf != 'function' ||
XMLHttpRequest.valueOf().toString() != 'function XMLHttpRequest() { [native code] }') {
return false;
}
return /native code/.test(api.toString()) && typeof api !== 'undefined'
}

console.error(isNative(XMLHttpRequest))
```
```

visited 属于个人隐私无法识别
除非配合访问的链接后端一起处理可以判断

@musi 测试好像是不行了，奇怪昨天我测试还可以，我待会再试试
不过不用纠结这个，因为这个最终还是有漏洞的，你可以看看我最新的代码如何绕过

@musi
应该是这句 != 'function XMLHttpRequest() { [native code] }'
这个在不同环境下有一点差异所以需要尝试下多种环境,我使用的 chrome90，其他版本或 firefox 的话需要针对性判断下
你可以先 console.log(XMLHttpRequest.valueOf()) 拿到真实值替换进去再测试

我想到一种结合 valueof 的判断方式 ，大家考虑下如何可以绕过
```
function isNative(api) {
if (typeof XMLHttpRequest != 'function') return false;
if (typeof XMLHttpRequest.valueOf != 'function' ||
XMLHttpRequest.valueOf().toString() != 'function XMLHttpRequest() { [native code] }') {
return false;
}
return /native code/.test(api.toString()) && typeof api !== 'undefined'
}

console.error(isNative(XMLHttpRequest))
```
不过最终始终有疑问，如果客户端可以针对性劫持的话，那无论怎么写代码都无法判断的，客户端只需要在判断函数 return true 就行了

@musi 正常是可以判断的，你可以运行下

不过...
@luofeii @BoringTu
正如 @gamexg 提到的，iframe 仍然不完美，客户端仍然能进行攻击，举个栗子
```
document.createElement = () => {
return {contentWindow: {XMLHttpRequest: XMLHttpRequest}}
};
document.body.appendChild = () => {};
var iframe = document.createElement('iframe')
document.body.appendChild(iframe)
console.log(XMLHttpRequest === iframe.contentWindow.XMLHttpRequest)
```
最后判断始终是 true，除非你继续证明 document.createElement 也是原生，这。。。俄罗斯套娃
我觉得可以考虑从某些无法被覆盖的对象入手，例如 navigator 之类

抛砖引玉
```
　　 var iframe = document.createElement('iframe')
　　 document.body.appendChild(iframe)
　　 XMLHttpRequest === iframe.contentWindow.XMLHttpRequest // true or false?
```

跟 go 没关 网络 /传输规范定的
这也就算中层，已经算好用了，你要是去做更底层对接才吐血

@SuperMild 这个暂时还没发现，不过就算有类似问题也对我影响不大，我是每天一个版本都会备份，即使少数出现问题，也问题不大，毕竟还有 nas 保障

个人隐私风险控制在本地、敏感信息、隐私照片、可能因违规而被扫描或删除的文件等，都可以安心备份
是如何实现的，有加密 /混淆机制？
我目前就是数据都放 nas 然后备份到百度云，重要数据 zip 加密压缩

这种简单功能，不想第三方就自己写代码调用 api 吧也就几行

执行力真强
不过作为一个 git 患者 想吐槽下 commit msg

用指针应该有办法判断，但并不是好办法，最好还是听楼上的意见自己处理关闭

酒路 wineflow

别搞那么多花样 SSL 是最稳的 诞生的目的就是为了解决不可信网络的可信通信
如果不支持 SSL 那就自己网络层加上公私加密 毕竟是经过全球验证的可靠通信算法