用户中心 建设 第1篇
const NO_NEED_LOGIN_WHITE_LIST = ['/user/register', loginPath];
复制代码到中：
注册一下，看一下数据库有数据，成功。
如果code为0表示成功，就直接取出响应的data，这样的话前端就不需要做修改了。
属于.umi，它是这个框架⾃动帮我们⽣成的⽂件
测试一下：已经正常地抛出错误了
非管理员：
管理员：
用户中心 建设 第2篇
使用插件mybatisX：MyBatisX 插件，自动根据数据库生成：
tips:在配置文件 中添加如下配置：
以上第二步检验密码是否正确时，查询数据库时，会把逻辑删除的用户数据也一并查出 来，所以需要对 mybatis-plus 框架进行设置
（1）连接服务器端后，得到一个 session 状态（匿名会话），返回给前端
（2)登录成功后，得到了登录成功的 session，并且给该session设置一些值（比如用户信息），返回给 前端一个设置 cookie 的 ”命令“ session => cookie
（3）前端接收到后端的命令后，设置 cookie，保存到浏览器内
（4）前端再次请求后端的时候（相同的域名），在请求头中带上cookie去请求
（5）后端拿到前端传来的 cookie，找到对应的 session
（6）后端从 session 中可以取出基于该 session 存储的变量（用户的登录信息、登录名）
指定接口全局 api
用户中心 建设 第3篇
用户侧前台业务需求架构依然不变，产品运营侧后台业务需求则抽取独立的 web / service / db 来支持，解除系统之间的耦合，对于“业务复杂”“并发量低”“无需高可用”“能接受一定延时”的后台业务：
（1）可以去掉service层，在运营后台web层通过dao直接访问db；
（2）不需要反向代理，不需要集群冗余；
（3）不需要访问实时库，可以通过MQ或者线下异步同步数据；
（4）在数据库非常大的情况下，可以使用更契合大量数据允许接受更高延时的“索引外置”或者“HIVE”的设计方案；
总结
用户中心，是典型的“单KEY”类业务，这一类业务，都可以使用上述架构方案。
常见的数据库水平切分方式有两种：
（1）范围法；
（2）哈希法；
水平切分后碰到的问题是：
（1）通过uid属性查询能直接定位到库，通过非uid属性查询不能定位到库；
非uid属性查询，有两类典型的业务：
（1）用户侧，前台访问，单条记录的查询，访问量较大，服务需要高可用，并且对一致性的要求较高；
（2）运营侧，后台访问，根据产品、运营需求，访问模式各异，基本上是批量分页的查询，由于是内部系统，访问量很低，对可用性的要求不高，对一致性的要求也没这么严格；
针对这两类业务，架构设计的思路是：
（1）用户侧，采用“建立非uid属性到uid的映射关系”的架构方案；
（2）运营侧，采用“前台与后台分离”的架构方案；
前台用户侧，“建立非uid属性到uid的映射关系”，有四种常见的实践：
（1）索引表法：数据库中记录login_name与uid的映射关系；
（2）缓存映射法：缓存中记录login_name与uid的映射关系；
（3）生成uid法：login_name生成uid；
（4）基因法：login_name基因融入uid；
后台运营侧，“前台与后台分离”的最佳实践是：
（1）前台、后台系统 web/service/db 分离解耦，避免后台低效查询引发前台查询抖动；
（2）可以采用数据冗余的设计方式；
（3）可以采用“外置索引”（例如ES搜索系统）或者“大数据处理”（例如HIVE）来满足后台变态的查询需求；
用户中心 建设 第4篇
大数据背景下的用户体验度量需要包含了问卷收集用户的主观感受，也要包含行为埋点产出的客观指标。通过主观感受形成感知指标结合行为埋点形成的技术指标相结合的方式进行度量，这样的用户体验度量就会涉及很多维度，一个合适的体验度量模型就显得非常重要。接下来进讲解本文的核心部分 --- 体验度量模型。
PULSE，传统 Web 产品体验评估指标，由 Google 提出，PULSE 的每一个字母代表一种指标：
PLUSE 是基于商业和技术来评估产品的，是跟踪产品的整体表现，无法直接通过指标观测用户体验是怎么样的。
HEART，是在 PULSE 的缺陷上，加以改进形成的以用户为中心的体验度量模型。Heart模型是从宏观的角度来衡量用户体验的有效性指标，这个指标会影响到公司策略。
（现代的体验度量模型有很多，但是大部分都是基于谷歌的HEART模型派生出来的。）
大量实践中，谷歌团队发现他们所监控的用户体验数据指标可以聚类归为5个类别，即度量用户体验的5个维度：愉悦度、参与度、接受度、留存率、任务完成度。
HEART用户体验度量模型有两个步骤，产品可以在确认要调研的：
HEART模型有五个维度，对于不同形态的产品的侧重点不一样。可以参考业务类型做出选择。比如：
UES（User Experience System）是阿里云设计中心通过多年设计实践中沉淀下来的云产品使用体验度量系统，用于ToB的云厂商的用户体验度量模型。
根据 B 类技术产品特性，在多个维度中评估和挑选，重新思考定制，设计了 UES 模型的五个维度：
易用性 - Ease of use
易⽤性是产品使用质量的核心维度，它反应产品对⽤户而言是否易于学习和使用，包含易学性、易操作性和清晰性3个维度。易⽤性的提升可以促进操作效率和任务完成率的提升、降低学习成本、提升⽤户体验和满意度。
一致性 - Consistency
一致性指多款产品间通用范式部分的一致程度，分为整体样式、通用框架和常用场景及组件等维度。对于⽤户⽽⾔，体验⼀致性的提⾼可以降低⽤户的操作时⻓及错误率，降低学习成本，提升⽤户的满意度；对于产品设计及开发者⽽⾔，保持体验⼀致性可以提升开发效能，产品模块的可集成性、稳定性和可延续性更⾼。
满意度 - Happiness
满意度反映着用户对产品或服务的期望被满足的程度，这个指标一定程度上会反映用户再次使用和对产品进行推荐的程度。
任务效率 - Task Success
任务效率包含任务完成率和任务完成时间，云产品的任务链路相对复杂，针对有明确任务或有固定使用流程的产品，通过比对用户路径和产品设计的理想路径之间的差异，能够帮助我们发现产品流程设计上的问题。
性能 - Performance
监控性能的指标有很多，其中最影响用户感知的指标是首屏渲染时间（FMP），指用户从发出请求到看到控制台主要内容的时间。其次，还包括页面请求响应时间、API 请求响应时间等指标。
用户中心 建设 第5篇
索引表法的思路是：uid能直接定位到库，login_name不能直接定位到库，如果通过login_name能查询到uid，问题便能得到解决。
具体的解决方案如下：
（1）建立一个索引表记录login_name与uid的映射关系；
（2）用login_name来访问时，先通过索引表查询到uid，再通过uid定位相应的库；
（3）索引表属性较少，可以容纳非常多数据，一般不需要分库；
（4）如果数据量过大，可以通过login_name来分库；
用户中心 建设 第6篇
我们如何管理体验？现代管理学之父，彼得·德鲁克说： If you can’t measure it, you can’t manage it。「如果你不能很好地度量它，也就无法有效地管理它。」
度量又称测量、计量，是指对于一个物体或是事件的某个性质给予一个数值及单位，使其量化而可以和其他物体或是事件的相同性质比较。
比如，如何评价一个美女的体型测试（是否性感），可以挑选一群美女（样本量），通过长度和重量的方法估计（度量工具）。测量出身高、三围和体重等维度数值，之后整理数值计算出每个人得分，最后进行排名（数据分析）。就可以需要测量的个体在哪个区间，再可以通过个体维度值和整体的指标相比较，就可以有针对性改善哪个维度的数值，以获取更好的排名了。
这只是一个简单度量，真实的选美比赛，除了身高、三围和体重（技术指标），还有评委和观众主观打分（主观感受，感知类指标）
测量长度使用尺子。考察学习的效果，使用万恶的考试卷子。
用户调研的方法有很多种：
但是这些调研方法样本太少，缺乏可信度！在大数据背景的追求更多更全的用户数据，往往采集线上用户的真实数据，就剩下面这两种方法：
*笔者刚好是在大型公司负责问卷平台建设，而且还有过埋点系统开发经验。
体验度量的核心是用户在使用产品的过程，对关键环节进行埋点（行为&性能），并通过邀请用户填答形式（问卷回收）收集用户主观感受，并对这些数据进行量化分析、并持续监测，以改进用户体验。
度量能回答以下问题：
度量是中立客观的视角，能为决策者提供有效的信息辅助决策：