竞品分析时不知道用什么方法？作者总结了8种常用方法和其适用场景。

实现多项目的分模块打包，且项目之间共享组件和依赖，运行、打包时互不干扰。

转转作为国内头部的二手闲置交易平台，从2015年成立至今，业务模式由C2C拓展至B2C、C2B、B2B、C2B2C等多模式并存的新格局，品类覆盖手机3C、图书、游戏、奢侈品等三十余大类。

转转目前采用的是中台业务架构模式，中台（全文默认指交易中台）负责提供通用，稳定的交易能力，灵活快速响应前台业务需求；业务负责前台探索持续创新，为用户提供有价值的服务。

介绍在Vue中3种页面级别前端灰度新功能的方案。

最近也许是“幸存者偏差”的原因，频繁看到不同技术公众号发布的关于《分库分表》的测试方案分享，21 年下半年中台订单侧也做了一次分库分表的技术改造，由于 21 年年底项目忙，一直没有系统性的整理一下，趁着最近有点空闲，来一次沉浸式总结；按照最简单的叙述，分为“事前”、“事中”、“事后”做一次回顾。

转转推送系统（后面简称系统）在早期设计中主要考虑了三个核心指标：

• 吞吐量：指系统在单位时间内能够发送多少消息的能力。
• 扩展性：指系统在快速支持更多APP主体、发送策略、发送通道、通道策略等能力上的难易程度。
• 性能：指系统API的接口耗时。

为了同时满足三个核心指标，我们在系统中大量采用了异步、并发、批量等设计。这些设计虽然很好满足了系统设计指标，但是同时也给系统带来了较高的复杂度，再加之一些环境因素（如测试环境的不稳定），导致业务方（指系统使用方）在接入测试中经常需要系统人员协助定位问题，这种状况既降低了业务方的开发效率又增加了系统的维护成本。

为了解决业务方的接入测试问题，在之后的系统演进中我们又增加了第四个指标：易测性，希望通过这个指标来提高系统的可测试性和降低系统测试成本。本文将重点讲述我们在系统易测性指标上的一些设计经验供大家参考。

瀑布流是大家日常开发过程中经常遇到的一个场景，我们公司内部的组件库中也提供了一些解决方案。但这些方案适用场景都很单一，且每个实现方案都或多或少存在一些问题，基于此，我们设计与开发了一个兼容多场景的瀑布流组件。

公司现在访问测试环境方式，使用线上域名，本地配置host，通过host控制访问不同的环境。这种使用方式，存在诸多问题，比如：

• 忘修改host，或浏览器存在socket缓存，host没生效。会访问更改线上数据，风险大。
• 需要频繁配置修改host，产品，运营，测试在测试环境作业中效率较低。
• 与第三方联调时，每次更换测试环境，都需要运维同学更改nginx配置。

如何将游戏类运营活动赋予新的玩法，打破老套运营方式给予用户新鲜感？

本文旨在为大家提供 Fair 在实际项目中落地的完整案例，包含了使用 Fair 进行动态页面改造、复杂场景使用、接入过程中遇到的问题、Fair 接入前后的性能对比、热更新方案设计等等内容。

我们在 Vue2编写组件的时候，会在 props、data、methods、computed 等 options 中定义一些变量。在组件初始化阶段，Vue内部会处理这些 options，即把定义的变量添加到了组件实例上。等模板编译成 render 函数的时候，内部通过 with(this){} 的语法去访问在组件实例中的变量。

那么到了 Vue3，新出现的setup启动函数，是整个组件逻辑组织的入口，我们可以在它内部写composition-api，以更加直观的形式声明变量，有利于代码的逻辑组织和复用，但是我们要明确一点，composition-api 属于 api 的增强，它并不是 Vue3 组件开发的范式，如果组件足够简单，还是可以使用 options-api，在了解了 composition-api的应用场景和使用方式后，我们需要进一步思考，setup启动函数是如何执行的，它所返回的数据又是如何与模板建立联系的？

高效率、低成本，一种快速上手的流量回放方法。

又到了每年晋升述职的时间，在过去的 5、6 年里，我以评委身份参与了大量的晋升述职（主要是前端，也包括客户端和测试），也辅导了许多（100+）组内外的同学，指导他们书写和完善 PPT。过程中我发现大家有许多共性的问题，这些问题导致了某些同学，明明有 80 分的能力，却让评委觉得只有 60 分。而有些掌握了晋升技巧的同学，同样 80 分的能力却能给评委 90 分以上的感觉。

后来，基于这些共性的问题，我制作了一个 晋升述职PPT模板，把晋升述职相关的注意点，包括述职准备、内容结构、表达技巧、规划重点等都集成到了这个 PPT 模板中。因为准备 PPT 是晋升述职的核心工作，所以把需要注意的点都融入到 PPT 里面后，在写 PPT 的同时就能融汇贯通起来。

转转支付中心与多家第三方支付平台、金融机构存在合作，例如微信、支付宝、分期乐、合利宝、平安银行等。

在收单、打款、退款等业务上，大部分接口都需要通过HTTP协议与第三方进行交互。

目前业界上或转转内部都有封装好HttpUtil工具类提供使用，但开发人员在接入三方渠道时，不同渠道方提供的文档有所差异且内部研发人员变动等原因，实现时自然会存在一些问题：

• 缺少统一的设计流程，代码复杂臃肿、耦合度高
• 开发人员水平参差不齐，不同人的设计风格千差万别
• 抽象程度不够，复用性较低

由此，支付中心研发了统一设计风格、注解式的HTTP客户端，建立一套面向“使用HTTP协议与三方渠道交互“的“设计规约”。

如何实现一个像“蓝湖”那样的标注功能，这篇文章带着你一步步的去揭秘关键性的技术点，让你从零开始上手一个sketch标注。

DeepLink是什么？如何应用DeepLink来获客引流？