js 怎样判断用户是否在浏览当前页面？

这样：

//网页当前状态判断var hidden, state, visibilityChange; if (typeof documenthidden !==

"undefined") {

hidden = "hidden";

visibilityChange = "visibilitychange";

state = "visibilityState";} else if (typeof documentmozHidden !== "undefined") {

hidden = "mozHidden";

visibilityChange = "mozvisibilitychange";

state = "mozVisibilityState";} else if (typeof documentmsHidden !== "undefined") {

hidden = "msHidden";

visibilityChange = "msvisibilitychange";

state = "msVisibilityState";} else if (typeof documentwebkitHidden !== "undefined") {

hidden = "webkitHidden";

visibilityChange = "webkitvisibilitychange";

state = "webkitVisibilityState";}// 添加监听器，在title里显示状态变化

documentaddEventListener(visibilityChange, function() {

documenttitle = document[state];}, false);//初始化页面状态documenttitle =

document[state];

扩展资料：

注意事项

浏览器对象有onfocus 和 onblur事件可以监听。但是触发这两个事件的前提是页面之前是focus过的。也就是说页面刚刚渲染完，用户在没有页面上任何 *** 作时，页面是不会正常监听这两个事件的；或者页面在打开状态下，但是触发了onblur之后并无页面 *** 作的情况下也不会正常监听这两个事件。

直到，用户 *** 作页面触发focus，之后离开页面才会触发blur，再次点击到当前页面时才会触发focus，如此反复都会触发相应的事件。

触发onblur事件的情况：

1、在chrome浏览器下，点击console面板也会触发blur事件，同样的，前提是之前是focus的状态。

2、页面最小化。

3、浏览器切换tab页面。

4、页面中的任何d窗。

5、focus状态下切换到其他应用。

前端任务点，编写登录请求函数，和 用户注册 类似，前端拿到用户名和密码发起 POST 请求。

收到 token 如何持久化存储，如何让每次请求都携带 token 是这里的点。

用户登录的接口详情可以点 这里 。

这里有可以优化的点，未来可能需要添加验证码等附加信息，这个时候就需要添加函数参数，就会比较麻烦，可以将参数数据格式包装成一个对象。当然，这里还是使用第一种方法了。

这不是重点，重点是登录成功后，我们要做的事情。

按照接口约定，登录成功我们可以得到如下信息：

这里我们要用到 token 字段，是我们现在有 token 了，但一刷新就没了，所以我们要做一下持久化存储，你想存哪里就存哪里，只要你能找到。这里就存储 localStorage 中了，在 Chorme86 中你甚至可以存到一个本地的文本文件中，只不过读取速度比较慢罢了。

除了 token，我们还要将用户信息存下来，比如首页展示用的用户头像等信息。

关于本地信息的安全性问题，本地保存的用户信息并不作为数据请求的凭证，仅供展示使用，当用户更改本地的用户信息对于登录的状态不会有影响，因为后端的判断依据是 token，token 有效就登录成功，而不是说本地存储的用户信息是谁服务端就认为你是谁，前端是不可信的。这种登录方式的危险点在于用户 token 被盗，但这很难避免，最不安全的是人。。。

登录成功，返回首页，用户名或者是用户头像并没有同步更新，这是因为，这里是单页应用，你在 login 页面将登录用户信息存到 localStorage 中，然后跳转到了首页，此时页面没有刷新，而 localStorage 中的信息没有及时更新到 DOM 中，此时的用户信息还是你没有进入 login 页面的用户信息，自然是无法展示的，怎么解决呢？很简单，刷新一下。

当页面刷新时，用户信息会从 localStorage 中读取，显示的就是现在的登录用户了，但。。。

我不想刷新。

也很简单，搞成响应式数据就好了呀。来人呀，上Vuex。

当你将 token 存在 cookie 中，前端并不需要主动设置，默认就携带传给了服务端，而这里我们存到 Authorization 中，就需要我们设置一下，拦截请求，在请求发送前添加 token。

好的，来捋一捋流程。

用户访问 /login，被前端路由处理，指向Loginvue，用户看到登录框，填入自己的账号，当用户填写账号时，name password被实时监听，同时会对登录按钮的可 *** 作产生影响，只有当用户将账密输入完整时，登录按钮可用。

前端收集用户信息，调用 network 中封装的 longin 请求函数，该请求发送前被拦截，添加 token，可能为空，使用账密登录时，token没实际效用。

后端检查成功给响应，前端将响应中数据的 token 通过触发 mutations 更新 Vuex 中 state，同时，将该 token 存到 localStorage，以免用户关掉页面导致 token 丢失。

登录成功跳到应用首页，用户头像等信息通过 Vuex 获取，因为 Vuex 中的数据是响应式的，此时从 login 跳转到首页，用户头像等信息也会得到相应的更新。

当用户新增文章时，只需向服务器传文章数据就可以了，而对于文章作者的相关信息则由后端从请求头中的 token 解析得到，这里需要注意，前端不要将本地的用户信息作为准确的作者信息，对于用户可以伪造的信息要做最小化的信任，用户完全有能力将本地用户名从张三改为李四，而最终作者是那个则需要由用户提供的 token 来判定，虽说 token 也有可能被伪造，但难度相对较大，往往是被窃取的可能性更大。

无密码登录其实还是需要“密码”的，只不过是换了一个临时性的对人不可读的字符串来代替罢了，并且每次请求帮你填好了。

在不考虑安全性的情况下本质上其实就是你将密码存到了浏览器里，然后你每次访问网站时让浏览器帮你输入用户名和密码，这个过程你是无感知的，这样自己就不用像个憨憨一样每次刷新就要填一遍表单。

填表是一件非常无聊的事。

要学一波 TypeScript 了呀。

用户并发登陆时前端怎么设计
减少访问API或者不访问 这个项目主要开发了3个页面,活动规则页面、抢红包页面、中奖名单页面。最开始的方案是活动规则页面的活动规则是通过请求api从服务端获取,这是通常的做法,好处是开发完成后不再需要技术人员修改代码,运营人员直接在后台修改富文本编辑器就可以更新页面,很灵活,适合长期存在、活动有变更的项目。但是对于抢红包这个项目,6天活动时间结束后即可下线,为了保证稳妥性,防止大量用户并发访问导致服务器瘫痪,后来把从服务端获取活动规则的借款去掉了,直接在页面中写死数据。 在中奖名单页面的开发中,也是一样的道理,但是这个就稍微复杂一些了,由于抢红包页面采用的是静默授权的方式,服务端数据库中只存了用户的openid,而中奖名单页面需要显示用户微信头像、微信昵称,这样才具有公信力,否则只摆出一个openid,用户会怀疑活动的真实性。 方案已经是确定的,中奖名单的数据还是采用写死的数据,不访问API,那么对于我而言,开发方式就有点变化了,我需要从服务端获取到3月31日的中奖名单前100名,然后遍历这一百天数据的openid,使用access_token 和openid获取用户的头像和昵称后,以数组的形式存入到一个数组中。页面加载的时候其实是每次取这个数组中的10条数据。具体实现方法我写了了demo,有时间再补充。 2h5静态文件资源与API请求部署到不同的服务器 做最坏的打算,为了防止服务器瘫痪后,用户打开页面显示404或者503,我把前端静态文件中的js、css、等资源都放到七牛服务器上,为了防止跨域,html文件还是和API放在同一台服务器上。这样,即使我们自己的服务器瘫痪了,用户依然可以正常打开页面。 3对于高访问量接口使用分时请求

前端短信验证码登录可以自动登录。方法如下：
1、前端登录页面手机号验证码登录页面。按钮样式都是自己写的class，按钮实际上是用的div+a标签来实现的，添加了动态的样式。
2、前端获取验证码的函数。先进行手机号的判空处理，为空则提示用户不能为空，再使用正则表达式对手机号码进行限制。
3、后端获取验证码代码。从平台上获取相关参数，填入。调用它们平台提供的发送短信验证码的接口函数，查看是否发送成功，发送成功则将该phoneNum-verifyCode用键值对的形式存到redis数据库，有效时间为5分钟，5分钟之后自动过期，提示用户需要在5分钟之内填写完毕并登录。
4、注册功能前后端的实现。多几个判空条件（如名字、密码不能为空，用户是否存在，手机号是否已被注册，用户名是否已被注册），实现的流程相似，先通过手机获取验证码，将发送成功的验证码存到redis数据库，有效时间为5分钟，然后用户填写验证码，前端向后端发送请求，后端验证是否正确，正确则返回注册成功。

四种方式

Cookie 出现的原因： >