上一篇文章中我们谈到了SPA（Single-page application）的出现，但SPA的应用有个需要解决的问题，就是浏览器只加载记录了一个html，所以当刷新浏览器时js会重新执行，当前页面的内容便会丢失；页面跳转时浏览器不会向服务器发出新的页面请求，浏览器也就无法前进、后退页面。

所以前端web路由需要实现以下目标：

（1）能根据页面URL来获取不同的模块，但不发起新的页面请求；

（2）能监听URL的变化。

而hash和history这两种模式便是其实现原理。

云朵、山脉、泥土、树木都是大自然的鬼斧神工，但如何使用计算机模拟出这些自然界的纹理呢？

Go作为一种编译型语言，经常用于实现后台服务的开发。由于Go初始的开发大佬都是C的老牌使用者，因此Go中保留了不少C的编程习惯和思想，这对C/C++ 和PHP开发者来说非常有吸引力。作为编译型语言的特性，也让Go在多协程环境下的性能有不俗的表现。但脚本语言则几乎都是解释型语言，那么Go怎么就和脚本扯上关系了？请读者带着这个疑问，“听” 本文给你娓娓道来～

经常有一些同学问我，非产品如何转型做产品经理？测试如何转型做产品经理等等，诸如此类的问题。最近重看了一些类似人人都是产品经理，数据产品设计等等的书。在此，就书中所述，结合自己的一些感受，浅谈下转型产品经理的一些看法，由于本人之前都是做游戏运营的，相关产品经理工作接触也是刚起步不久，因此概念类学习内容较多，希望抛砖引玉，跟大家多多交流。

一文带你了解 Mesh、MCU 和 SFU 三种多人音视频的传输架构异同。

存量竞争时代的核心是用户的留存与复购，即用户粘性。从单纯关注DAU，时长，消费量等规模指标到注重效率，需要对和用户粘性高度相关的要素进行更精细化的分析。本文介绍一类统计学习模型，对个体颗粒度的用户粘性及相关要素进行规范统一的建模，提炼统计显著的因子，辅助业务指定指标体系，生成运营策略。

早期从事运单系统的开发和维护工作，从最早的日均百万单，到日均千万单，业务的快速发展再加上外卖业务的特点是，业务量集中在午高峰和晚高峰两个高峰期，所以高峰期并发请求量也是水涨船高，每天都要面对高并发的挑战。拿运单系统来举例，日常午高峰核心查询服务的 QPS 在 20 万以上，Redis 集群的 QPS 更是在百万级，数据库 QPS 也在 10 万级以上，TPS 在 2 万以上。

在这么大的流量下，主要的工作也是以围绕如何建设系统的稳定性和提升容量展开，下面主要从基础设施、数据库、架构、应用、规范这几方面谈谈如何建设高并发的系统。以下都是我个人这几年的一些经验总结，架构没有银弹，因此也称不上是最佳实践，仅供参考。

在如今搜索领域中，简单的关键词匹配已经无法胜任全量的query，如果能够识别出query的意图，对于返回类型多样性，提升相关资源占比以及关联相关结果更加有效。所以Query的意图识别尤为重要，在一些垂直领域中，query意图识别也演变为类目识别。借着近期工作内容，梳理一下在垂直领域下query的类目识别。

在《腾讯文档-构建科学有效的色彩系统》这篇文章中，我们阐述了腾讯文档如何升级了新的品牌色，为腾讯文档塑造更加有未来科技感及智慧感的视觉感受和品牌认知，以及如何构建一个科学有效的调色板。

在设计系统的实际运行中，我们也需要着眼于如何应用调色板，建设协同工作流，并给各个角色提供有关色彩的扩展指导，以达到在腾讯文档中构建一致且有品牌感的数字界面并有效提升效率的目的。

NodeJS 目前已经诞生了 11 年，一般当 NodeJS 项目成长到一定阶段后，就不可避免要遇到许许多多的事故，例如服务器无故宕机，线上逻辑出现问题，其中的排查手段多种多样，但是我认为最好的还是拥有细致的上报，是排查这些问题的利器。

垃圾回收的第一步是什么呢？要找到垃圾，如果我们反其道而行之，找到所有的存活对象，是不是也等于找到了垃圾呢? 本文想要探讨的gcDrain函数就是使用三色标记法找到存活对象的一个重要函数，了解gcDrain函数就会对golang垃圾回收机制有更深的理解。

在目前的日常工作中，我们的视野往往只着眼于屏幕上的人机交互，我们的身体也很少离开办公室以外的环境。那么，是否有一些思维方法，能够帮助我们站在更加宏观的角度上去思考问题，去探索更广泛的设计机会呢？

腾讯文档列表页在不久前经历了一次完全重构后，首屏速度其实已经是不错。但是我们仍然可以引入 SSR 来进一步加快速度。这篇文章就是用来记录和整理我最近实现 SSR 遇到的一些问题和思考。虽然其中有一些基础设施可能和腾讯或文档强相关，但是作为一篇涉及 Node、React 组件、性能、网络、docker 镜像 、云上部署、灰度和发布等内容的文章，仍然可以小小地作为参考或者相似需求的 Checklist。

本文主要分享了一个适用于Android App的代码Native层的so库动态加载方案，这套方案能让App在程序运行时热更新so库，并一定程度上降低App常驻内存。

随着推荐技术成熟以及信息流业务极速扩张，用户与内容的交互模式逐渐从“人找内容--搜索”往“内容找人--推荐”迁移，并且这种趋势仍在扩大它的外延边界，大有“万物皆可推荐”的架势。但搜索作为人与内容交互的一种重要方式，它的作用并没有削弱，用户在推荐场景的沉浸消费反而会激发出新的搜索需求。从本质上看，搜索与推荐这两个飞轮咬合的轴心点是用户兴趣，因此如何在当前内容分发场景中更好满足用户兴趣是搜索技术精进的一个重要命题。经过两年的技术锤炼与业务实践，我们在兴趣搜索领域积累了一些心得和成果，汇总成文，分享于斯。

在使用 React 之前，不知道小伙伴们有没有遇到过 更新卡顿 的问题，如下为 React 应用更新时的火焰图，JS 执行 287 ms 后，渲染任务才开始（25.4ms）。

主流浏览器刷新频率为 60Hz，即每 16.6ms 浏览器刷新一次，每 16.6ms 要完成 JS 执行、重绘重排。而 JS 线程和 GUI 线程是互斥的，在浏览器的一帧里（16.6ms）JS 脚本执行和页面渲染是同步执行的，一旦 JS 脚本执行时间过长，页面就会出现掉帧卡顿。

为了减少 JS 脚本执行的时长，React 重写了架构来解决卡顿问题。