扫码关注官方订阅号
通过看你的问题和对其他答主的回复来看。你觉得后端实时查询在用户多的时候会数据库压力过大，所以准备放到用户端，让用户提交时自带等级信息。
这个方案完全不可行，除非你密码学技术还有前段技术都是时代前沿的
具体来说：
如果这个网站使用量高了，那自然会吸引各路神佛，前端你再怎么混淆加密最终不都得变成js能识别的样子？这就和你觉得穿丁字裤太暴露改穿四角平头内裤一样，再咋加强你还是基本全裸的样子啊！
假如你的网站没有人会攻击你，那你的用户量也肯定不大，全放后端每次现查也来得及。况且后端还可以做缓存优化啊。
比如redis.再比如java的shiro; 这是个验证鉴权的框架，它自带 EHCache 缓存相关组件，你只需要配置一下就好。
redis
shiro
所以除非你用户量不算小，但你抠门到服务器垃圾的 和 搬瓦工 差不多的地步,否则还是在后端做缓存优化吧。
一般而言，靠客户端控制是不可靠的，还是要每次在服务端判断。
难度不是存数据库吗
你要放在客户端中保存，那么用户就一定可以修改，那么可以通过提高用户修改的成本来提高安全性，这就看你的cookie的设计巧妙度了
前端保存应该都没法保证不被用户修改吧，只是修改门槛的问题。无论是 Cookie 还是本地存储或者其他什么方式，如果有心人读了你的前端代码，应该都能解析出来，如果等级内容不是那么重要的话，尝试加密保存，混合用户名，手机号之类的用户数据做 md5 之类的加密运算然后存储，不过这样使用起来还是麻烦的，而且一旦用户知道了你的等级判断逻辑，破解起来也就没那么难了。
等级内容重要的话，最好还是每次从服务器端获取。
再说，反正每次页面刷新都要请求服务器，那就让服务端每次在页面中包含类似信息，前端取了存到 Js 变量中也是可以的。
不通过后端验证，难道用户等级提升了是在自己玩？不修改数据库？
这应该只是一个防篡改的问题吧？你只要把等级存在本地，然后把数据用一个服务器才知道的 key 来签名。每次提交的时候你只要校验签名对不对就知道数据是否被篡改。一般而言，计算签名比查询数据库的代价要小得多得多。
一般分成两张表来设计，一张存用户数据，一张存用户等级，用外键关联
微信扫码关注PHP中文网服务号
QQ扫码加入技术交流群
Copyright 2014-2026 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
PHP学习
技术支持
返回顶部
0 
8
350
收藏
通过看你的问题和对其他答主的回复来看。
你觉得后端实时查询在用户多的时候会数据库压力过大，所以准备放到用户端，让用户提交时自带等级信息。
这个方案完全不可行，除非你密码学技术还有前段技术都是时代前沿的
具体来说：
如果这个网站使用量高了，那自然会吸引各路神佛，前端你再怎么混淆加密最终不都得变成js能识别的样子？这就和你觉得穿丁字裤太暴露改穿四角平头内裤一样，再咋加强你还是基本全裸的样子啊！
假如你的网站没有人会攻击你，那你的用户量也肯定不大，全放后端每次现查也来得及。
况且后端还可以做缓存优化啊。
比如
redis.再比如java的
shiro; 这是个验证鉴权的框架，它自带 EHCache 缓存相关组件，你只需要配置一下就好。所以
除非你用户量不算小，但你抠门到服务器垃圾的 和 搬瓦工 差不多的地步,否则还是在后端做缓存优化吧。
一般而言，靠客户端控制是不可靠的，还是要每次在服务端判断。
难度不是存数据库吗
你要放在客户端中保存，那么用户就一定可以修改，那么可以通过提高用户修改的成本来提高安全性，这就看你的cookie的设计巧妙度了
前端保存应该都没法保证不被用户修改吧，只是修改门槛的问题。
无论是 Cookie 还是本地存储或者其他什么方式，如果有心人读了你的前端代码，应该都能解析出来，如果等级内容不是那么重要的话，尝试加密保存，混合用户名，手机号之类的用户数据做 md5 之类的加密运算然后存储，不过这样使用起来还是麻烦的，而且一旦用户知道了你的等级判断逻辑，破解起来也就没那么难了。
等级内容重要的话，最好还是每次从服务器端获取。
再说，反正每次页面刷新都要请求服务器，那就让服务端每次在页面中包含类似信息，前端取了存到 Js 变量中也是可以的。
不通过后端验证，难道用户等级提升了是在自己玩？不修改数据库？
这应该只是一个防篡改的问题吧？
你只要把等级存在本地，然后把数据用一个服务器才知道的 key 来签名。
每次提交的时候你只要校验签名对不对就知道数据是否被篡改。
一般而言，计算签名比查询数据库的代价要小得多得多。
一般分成两张表来设计，一张存用户数据，一张存用户等级，用外键关联