连续同源异步操作队列
问题的发现
来自同源的多个异步操作可能引起异步冲突问题，特别是在网络请求时。同源操作产生了两个ajax请求，它们的请求结果将用于渲染同一个区域，然而由于网络问题，先发出的请求后返回，导致最终得到的界面是错误的。
解决这个问题的最好办法，是利用原生XHR的abort方法，在后一次操作时，将前一次操作引起的ajax请求给cancel掉。
但是在现实条件下，异步操作并非都有cancel操作。js原生的Promise没有，原生的fetch基于Promise也没有。基于Promise的很多工具都没有cancel操作。这种情况下怎么解决这个问题呢？
其实方法是有的，就是直接丢弃Promise的推送，不执行它的resolve回调即可。这样，虽然异步操作已经执行了，但不会对现有的环境造成任何副作用。（虽然这样看上去浪费了异步操作这个资源。）
问题的思考
如何来判断是否要丢掉它的回调？我们可以创建一个队列，每次产生一个异步操作时，就将它加入到队列中，当队列中存在操作对象时，每次只取最后一个，等待它推送结果，执行它的回调，排在它前面的操作全部丢弃掉。
基于这样的想法，我写了一个工具deferer-queue。它为异步操作创建队列，并根据不同的场景实现不同的队列操作形式。你可以通过这里阅读它的源码和文档。它提供了4种可供选择的场景：
并联
异步操作进入队列的时候立即开始执行，它们的回调将按照它们进入队列的顺序执行。
这个图中有这些元素：
- 时间轴
- 圆圈：一个异步操作被push进队列
- 向下箭头：队列中开始执行某个异步操作
- 虚线：执行顺序（执行流）
- 方框：每个异步操作的回调
- 竖线：队列周期（从开始到停止的过程）分割线
上图表现的是，1-4这4个异步操作在不同的事件点被加入到队列中。它们在一个周期内，也就是从1开始执行，到队列中所有的异步操作执行完毕，进入停滞状态。1-4这些操作，一进入队列就开始执行。它们执行完之后，就会告知队列执行完毕状态，回调就会执行。但是由于回调一定是按照异步操作进入队列的顺序执行的，因此，即使4已经完成了，但它的回调也必须等到3结束后才会执行。
在deferer-queue中，所有的回调一定遵循先进队列先执行，后进队列后执行的顺序规则。
串联
异步操作进入队列后并不立即执行，它从队列中取出第一个，执行，等待这个异步操作完成（成功或失败都算完成）并执行它的回调，然后再取出下一个，继续执行。
上图表现的是，1-4这4个异步操作，进入队列后，按照顺序依次执行。但是，在一个周期内，只有1是立即执行的，其他操作必须等到上一个操作结束（promise resolved或rejected）之后，才会开始执行。
尾调
异步操作进入队列后并不立即执行，它从队列中取出最后一个，执行，并把前面所有的操作丢弃，这个操作执行完后直接进入回调，队列结束。
这张图表现的是，1-4这个4个异步操作被按顺序加入到队列中，但是，在一个周期内，只有4（最后一个）被执行。1-3全部被丢掉了。你可能会问，假如4进入队列的时候，1已经在执行了怎么办？答案是，1会被丢掉，只要在一个周期内，只会有一个执行的回调会被执行。也就是说，假如4开始执行之后，突然5插入进来了，那么4会被直接丢掉，这一个周期以最后一个回调函数被执行而结束。
连续
异步操作进入队列后并不立即执行，它从队列中取出第一个，执行，等待这个异步操作完成（成功或失败都算完成）并执行它的回调，之后取出最新的一个执行，执行完之后再看队列中是否有新的，如果有新的，再取出最新的一个，继续执行，如此往复下去。
这幅图表面的是一种连续不断的执行队列的模式，当1-4被push进队列之后，1被执行，2-4被丢掉。当1完成之后，检查队列是否加入了新的异步操作，如果检查到5-6，那么取6进行执行，把5丢掉。进入后续过程后，感觉上和尾调非常像，但是，尾调是在一个周期内，只会执行最后一个回调，而连续不是，它会不断的检查队列是否已经被执行完，如果没有，那么就会执行一个类似尾调的过程，这个过程结束，又会再做一次。队列开始的时候，取第一个异步操作执行，当第一个操作结束后，后面之后去取最后一个执行。这些执行之间是串联关系，只有正在执行的异步操作已经完成的情况下，新的操作才会被执行。这是一种比较奇葩的场景，但是它可以解决一些需要连续不断做某些事情的应用。
注意：当一个周期结束后，队列处于停滞状态，但是，一旦有新的defer被push进队列，它又会开始一个新的周期。
问题的解决
基于上述的思考，我最终发布了deferer-queue，你可以通过npm安装这个包，在自己的项目中使用它。它的操作模式超级简单，首先实例化一个queue对象，然后往这个queue push异步操作，异步操作被装在一个函数中被push进队列，它的回调函数一定是按照push的顺序执行。
import DefererQueue from 'deferer-queue'
const queue = new DefererQueue()
const defer1 = () => new Promise((resolve, reject) => { ... })
const defer2 = () => axios.get(...)
const defer3 = async () => ...
queue.push(defer1).then(() => { console.log(1) })
queue.push(defer2).then(() => { console.log(2) })
queue.push(defer3).then(() => { console.log(3) })
无论defer1-3中的谁，执行后谁先返回结果，控制台输出的结果永远是1 2 3（defer都成功的前提下）。
要使用上述的四种模式，只需要在实例化的时候，传入一个options对象，将mode设置为parallel/serial/switch/shift中的一个即可：
const queue = new DefererQueue({
mode: 'switch',
})
其他的用法一样。这样，你的队列就会按照“尾调”的模式运行。
关于具体的API使用细则，你可以阅读它的文档。其中，利用axios的cancel能力那个地方非常有借鉴意义。
rxjs的Subject具有多播的特性。对于单播和多播怎么理解呢？
首先要了解一个概念“冷流和热流”。所谓“冷流”是指数据的变化是固定死的，举个例子：
let observable = Rx.Observable.create(function subscribe(obsever) {
observer.next(1)
observer.next(2)
})
observable.subscribe(v => console.log(v))
上面这段代码，subscribe的输出结果是可预知的，一定是先输出1，然后输出2.
“热流”是什么呢？就是它的数据变化是不可知的，随机的，随意的。例如通过fromEvent产生的observable。
现在回来说单播和多播。
单播是说，一个observable只能被一个观察者消费。还是用代码说话：
let observable = Rx.Observable.create(function subscribe(obsever) {
observer.next(1)
observer.next(2)
})
observable.subscribe(v => console.log(v))
observable.subscribe(v => console.log(v))
上面这段代码会输出两次1,2。简单的说，当调用observable.subscribe时，create的传入参数function subscribe会被调用一次。也就是说，一个subscribe只能被一个observer消费。这就是单播。这些observer之间相互不影响（不要有全局变量），它们虽然订阅同一个obserable，但是，它们仅仅是利用了observable的处理数据的能力，至于数据源、处理结果，都是独立的。
那什么是多播呢？就是一个有一个东西，可以被多个观察者同时订阅。这个时候要引进rxjs里面的Subject，它所创造的实例，能被多个观察者消费。代码说话：
let observable = Rx.Observable.create(function subscribe(obsever) {
observer.next(1)
observer.next(2)
})
let subject = new Rx.Subject()
subject.subscribe(v => console.log(v))
subject.subscribe(v => console.log(v))
observable.subscribe(subject)
这个代码和前面不一样的地方在于，observable被subject订阅，当subject被两个不同的observer订阅时，subject执行一次function subscribe，但是同时通知这两个observer。所以，当你得到的结果是：1,1;2,2时，应该一点都不觉得奇怪。在第一次执行next(1)的时候，两个observer同时被执行。
rxjs在编程实践中主要考虑三个部分：数据怎么来？数据怎么流动？怎么使用数据？
数据怎么来？rxjs有一大堆创建observable的东西，而这些东西，虽然创建的三observable，但实际上，它们就控制了数据是怎么来的。比如formEvent，表示数据是从事件中来的。比如bindCallback表示数据是从函数的运行结果中来的。总之，虽然rxjs不是我们传统的函数，没有主动调用函数时传入参数的概念，但是，它内部已经囊括了数据怎么来的各种方式，利用它的API就可以在特定的场景拿到你的数据。
数据怎么流动？完全靠rxjs的各种操作符，例如map、switch。除此之外，observable还能被组合。总之，observable虽然看上去是个形容词，但实际在rxjs代表那个用来装数据流的东西，是一个名词。而observable的形状（用了哪些操作符），决定了你或许数据的形式（时间上）和形态（空间上）。
数据怎么使用？实际上subscribe里面就决定了当数据流经observable之后，你怎么使用这个最后的数据。而且，rxjs可多值、多播。
RxJS中的概念梳理：
我们可以把一切输入都当做数据流来处理，比如说：
- 用户操作
- 网络响应
- 定时器
- Worker
RxJS提供了各种API来创建数据流：
- 单值：of, empty, never
- 多值：from
- 定时：interval, timer
- 从事件创建：fromEvent
- 从Promise创建：fromPromise
- 自定义创建：create
创建出来的数据流是一种可观察的序列，可以被订阅，也可以被用来做一些转换操作，比如：
- 改变数据形态：map, mapTo, pluck
- 过滤一些值：filter, skip, first, last, take
- 时间轴上的操作：delay, timeout, throttle, debounce, audit, bufferTime
- 累加：reduce, scan
- 异常处理：throw, catch, retry, finally
- 条件执行：takeUntil, delayWhen, retryWhen, subscribeOn, ObserveOn
- 转接：switch
也可以对若干个数据流进行组合：
- concat，保持原来的序列顺序连接两个数据流
- merge，合并序列
- race，预设条件为其中一个数据流完成
- forkJoin，预设条件为所有数据流都完成
- zip，取各来源数据流最后一个值合并为对象
- combineLatest，取各来源数据流最后一个值合并为数组
数据的管道是什么形状的？在RxJS中，存在这么几种东西：
- Observable 可观察序列，只出不进
- Observer 观察者，只进不出
- Subject 可出可进的可观察序列，可作为观察者
- ReplaySubject 带回放
- Subscription 订阅关系
前三种东西，根据它们数据进出的可能性，可以通俗地理解他们的连接方式，这也就是所谓管道的“形状”，一端密闭一端开头，还是两端开口，都可以用来辅助记忆。
琢磨近10年前端领域出现的框架，它们几乎在干同一件事，那就是，怎么做到使“界面”“事件”“数据”三者可以更分离，但又合理串联在一起。界面用于呈现，事件用于交互，数据用于内容，这三者构成了前端开发的最底层核心要素。但是，就目前市面上的框架而言，仍然没有做到完美。举个例子，react算是最热门的框架之一，然而，它自己内部去实现了一整套事件系统，这样的坏处是，它不能和DOM原生事件同时使用，否则会出问题。而DOM原生事件和界面又完全绑定在一起，这就使得类似jquery这类框架无法实现数据响应。而virtual dom的出现，解决了数据和界面之间的响应关系，但是仍然无法解决数据和事件的双向响应（vue里面有较弱的实现）。因此，我觉得，更舒服的编程方式是，要进一步在现在已有的成果基础上，继续提炼事件这个维度，要让交互抽象后独立于界面和数据。当一个交互发生时，它不需要在事件系统中去写有关修改数据的操作（例如react里面要用setState），也不需要在事件系统中去写界面改动的代码（backbone就需要在事件发生后去操作DOM来实现界面变化，jquery也是）。未来新的框架应该是，抽象出“界面”“数据”“事件”，将它们单独分开放置，再由框架内部将它们串联起来。开发者应该关心使用什么模板去呈现界面，使用什么数据去渲染内容，使用什么事件去响应交互。而不需要关系，当用户进行了某个操作（交互）应该触发什么事件，然后去修改哪个数据，实现界面的变动。
这样的编程方式，和MVVM完全是两种思路，希望真的有机会看到这样的库可以出现。
挣扎在逻辑抽象和业务环境的表单设计
这两天一直在写一个基于业务逻辑的表单抽象架构。听上去多么简单的一件事，不就是个表单么。然而，拥有这样想法的我果然还是太年轻。表单，可以说是web开发中最复杂的交互领域之一。单纯把表单理解为用户可以填写和提交的交互元素，那就太无知了，殊不知，一个表单除了填写和提交两个动作之外，还有一大堆可能需要的动作，例如数据验证、联动、按条件填写项、复原和暂存、创建和编辑表单公用等等。这些东西还完全没有考虑具体业务中的特殊逻辑，单纯从抽象层面去归纳而已。
而且，在现代SPA应用开发中，表单跟jquery时代也有巨大区别。SPA是数据驱动型开发模式，即界面如何展示，完全由数据（状态）驱动。这就会遇到很多问题，数据驱动的开发模式，不可避免的需要模板，模板中使用变量，并映射到实际提供的数据中。在模板中使用变量并不能方便的对应的数据层去，比如你在模板使用一个for in的循环，那么就有item和list。list好理解，但是，如果将item又传回给数据层呢？
除了数据层和模板映射的问题，表单的数据更改其实也是麻烦事。它依赖于框架内的事件系统，也就是说，现代前端框架，无一例外的要求你通过绑定数据，依靠自己内部的事件系统，当用户输入数据时，将数据的变化绑定到数据层去。这也就产生了一系列问题，几乎没有一个表单架构能够具备通用性。开发者无法在数据结构的便捷性、数据响应的便捷性、数据校验的便捷性之间得到平衡，它们一定是互斥的。我这两个星期都栽在这个问题上，无法自拔。
而且，当一些业务的特殊逻辑加入的时候，这个事情就更复杂。例如，表单中的某个（些）项目，仅在某个选项为true的时候才展示出来。这个听上去简单，但是，你要知道，当用户在true和false之前切换的时候，那些被显示/隐藏的被填写的数据要不要保留？另一个复杂的问题，就是数据源。一个下拉列表，它的选项列表可能是根据当前选中的某个项来决定，当未选中时，或重新选择时，要进行切换。这个问题听起来尚好解决，然而，当要求，其中某个选项为某值时，要求表单中其他某个项必须与它互斥……这样的特殊逻辑，不是不可能存在，我就遇到了，并且敲破了自己的脑袋。
真希望有人能够将表单这回事进行深度抽象，大老，靠你了……
听听音箱究竟还有哪里不对？
腾讯的生日是11.11，按理双十一应该被腾讯注册商标才对，可惜……腾讯的性格温和，能够做成事真的很幸运。在中国，要做一家有温度的公司，要做一家按照创业时的初衷行事的公司，要做一家以普通人为用户群体，用产品去服务他们打动他们的公司，真的是难到登天，唯独，腾讯这样做了20年，或许，今年之后，这样的腾讯也要转型了，要像产业互联网转变，不是因为不想继续做以用户为目标的产品，而是它不得不在市场竞争中活下去而面临转型。我08年高中毕业才有机会开始用QQ，10年，从用户变成员工，从喜欢它的产品，到去实现产品。
早上就拿到了公司发的周年礼物，由一个精美的大箱子装起来，包装精美，而且设计感十足，和它的产品一样，力求让人觉得有温度。如此隆重的包装，我觉得也有点浪费材料，不环保。
礼物中有腾讯自主研发的智能音箱“听听”，晚上回家体验了一下。
腾讯听听音箱
首先是颜值，不能说是最顶级的，毕竟只600上下的价格。但是整体而言，在同价位智能音箱中，算得上中上乘，我鹅的设计在国内还是顶级的。白色的上身，塑料感足，灰色网布的下身，音箱感十足。开关、接口、指示灯都遵循完美的对称原则，为了使这种对称更不拘一格，顶面采用斜面设计，增加了亲切感。
其次是音质，也算不上顶级，可能和音乐版本也有关系，非常浓的低音，放在桌面低音炮效果明显。也是因为这种明显的低音，不适合听现场音乐，音乐的细部会被和音盖下去。它不是专业的音响，更适合休闲，生活气息。
它的重量有点重，不适合便携。另外，AI功能需要联网支持，因此也只能在wifi环境下工作。
作为鹅厂人自己推出的AI音箱，它的AI语音交互是一个亮点。开机之后，只要你说出“9420”就能唤起AI小姐姐，然后你就可以告诉她你要干的事情，查询天气、听音乐、听小说等等。如果她不能马上理解你说的话，还会重新问你。据说，之所以用“9420”作为唤醒口令，除了它是“就是爱你”的谐音，还因为这个句法语音识别起来更容易，容错率更高。但是，代价就是比较难记，因为它有四个音节。虽然说错了也没关系，但是总有一种尴尬症犯的感觉。
在自然语言交流这个环节上，就目前整个行业的水平来看，听听算得上顶尖，响应速度快，识别准确，交流自然，非常流畅。当然，在情绪识别这个点上，还有待未来整个行业的提升。比如我很不耐烦的说下一首，它可能还无法意识到，我不喜欢当前这种音乐的类型。切换音乐类型，我能很明显感觉是后台的一个强制算法，比如连续切了两首之后，它就给我换了一个音乐类型。把玩之后，发现其实它也不过如此，主要还是依赖后台的AI算法。
当然，智能音箱市面上也很多，算不上独特的地方。而且，甚至在性价比上，还不如其他音箱，毕竟600RMB的价格不算是亲民，作为一款商业产品，注定会面临比较大的风险，甚至有可能卖不动都有可能。
但是，我认为听听是腾讯应该继续做的项目，主要从几个方面考虑：
AI落地产品。就目前整个市场而言，虽然AI话题火的足以燃烧市面上的所有现金，但是真正要把AI落地很难，因为一套算法只适用一个场景，而即使一个场景，算法也需要非常长的时间去学习和修正，特别是诸如自动驾驶这样庞大的AI系统，就连走在最前面的百度，也无法拍着胸脯说自己在自动驾驶上已经完全成熟，可以量产。而智能音箱则是一个非常好的切入口，它立足于非常小的场景，而且不要求非常准确，这就有了空间去逐渐打磨和完善。如果不落地一款AI产品，那么很难给市场信息，AI研究在公司内部也会被很多人质疑。所以，我觉得把这款产品做好，落地，打磨，非常重要，就像其他产品一样，前期不一定是市场上最有前景的，但公司有资源和钱推进它，让它在时间中逐渐淘汰那些资本推进的产品。
算法的完善。在AI领域，算法为王。就以同声传译为例子，这么简单的一个场景，AI仍然无法做到精确。要让AI越来越聪明，必须经过非常长周期的学习和调整，算法的优化。而通过智能音箱这样一个小场景，就可以达到这样一个目的。而且，一个用户，一旦拥有一个智能音箱，基本上不会再同时使用另外一个智能音箱，而且一个音箱的最低寿命也在半年以上，因此，对于长时间的针对单用户的学习和算法打磨，有非常好的作用。
平台。腾讯是一个做软件起家，以整合用户资源、内容资源为核心竞争力的公司。对于其他应用商而言，他们很难像腾讯一样，打通用户、音乐、视频、文学，而对于腾讯而言，文娱已经是整个公司的支柱之一，（我认为今天的腾讯，分为游戏、内容、投资三大块，这个话题我们以后讨论。）可以说能为用户提供最完善、最智能、最有效的视听服务。就拿音乐来说，QQ音乐经历了低谷期，慢慢积累沉淀，如今已经在国内市场没有任何竞争对手，准备独立上市，提供更优质的音乐服务，打通版权和商业，突破自己成为它最大的瓶颈。将这些平台整合起来，集公司各个事业群资源于一个小小的音箱上。在未来，这样的整合，可以被移植到车载系统、智能家具等其他设备上。音箱只是一个先行者，探路者，一旦这一平台模式成熟，那么面对未来各种可能，都可以心中不慌，从容面对。
总而言之，如果说听听是一款终极产品，我是不认同，毕竟它本身的缺陷很明显。它要做的有两个方面，一方面是继续打磨自身，像QQ音乐一样，慢慢沉淀，打磨出腾讯自己的硬件设备；另一方面，则是在AI算法上不断和公司整体层面的资源进行整合，把庞大的体系，浓缩为半尺大小的精华，为将来在其他领域的深入打下基础。
晚上准备写博客的适合，打不开网站，按照套路，这应该是需要重启apache的时候了。但是，打开自己的其他网站，发现竟然也打不开，经过摸索，发现是dnspod的问题，所有托管在dnspod的域名都无法访问。不知道是运营商线路还是什么原因，总之域名的dns服务宕了：
一头懵逼。吓得我以为自己写了什么敏感话题给官方封了呢……之后把dns切换到阿里云自己的服务，再做解析就好了。
微信小程序可能是近几年最耀眼的技术突破
当我们谈论微信小程序的时候，会有一种怪怪的感觉，我们会想尽一切办法找出这个点子是腾讯抄谁的。可是很遗憾，想来先去，也找不到，感觉小程序就像之前火过一阵的轻应用，于是感觉放心了，说来说去，也就是新瓶装旧酒。可是，我却认为，微信小程序，是近几年国内甚至国际上最耀眼的技术突破。
首先，我们要先确定一下为什么说它最耀眼。我之所以这么认为，是从产品的角度考虑。这世界上的产品无穷无尽，但是，真正有商业价值，并且就像一片空白，有待发挥巨大潜力的，并不多。早几年3D打印被认为不得了，可如今呢？之后VR火的不行，结果呢？如今，人工智能大行。一个产品，它是否具备非常大潜力的商业价值，要从它内在的实用价值，和它外在的市场规律去看。互联网技术的商业价值非常大，但在互联网早期，一切都是空白的时候，很多人看不到。互联网本身所带来实用场景颠覆毋庸置疑，问题在于，这样的颠覆是否符合市场规律？所谓符合市场规律，其实本质在于是否天时地利人和。中国最早的电商网站8848，它遇上错误的时间，互联网本身不普及，没有足够的信任体系（支付体系），快递成本高周期长，面向消费者的销售问题复杂。而阿里巴巴则看到这些弊病，它做了两件事：1.做企业间的生意，以商务解决互联网问题；2.即使再困难，也稳住不死，等待时机。对于微信小程序而言，它重新定义了一款服务的呈现方式，使商家可以脱离系统底层，快速开发服务，而且，小程序本身定了很多规矩，从某种层面讲，它用自己的方式制定了原则，这就像app store分发一样，有利于整个生态的良性循环。只要稳住不死不胡来，它就充满无限的遐想。
其次，为什么说它是技术突破？小程序底层要解决非常多兼容性问题，同时，它从另一个角度重新定义混合式开发的模式。它的开发方式和reactnative、weex很像，但是又不相同。一方面，它要解决reactnative一样的问题，即如何将基于前端技术开发的代码解构为可以和系统交互的代码，解决通信，解决视图渲染。另一方面，它要解决如何兼容微信所依托的整个平台，以及底层的系统。很多人觉得，我有一套H5就够了，微信里面照样可以被传播不是吗，干嘛非得有一套小程序呢？我们不从商业角度去考虑，而从技术出发。小程序给了开发者另外一片天地。在小程序之前，前端开发基本就是面向浏览器，面向浏览器的开发必然遇到浏览器本身的瓶颈。而小程序提供了另外一种可能。它用规范化的语言方式，并且在后台提供微服务，让编程更像是以最终产品为导向，而非以过程解决问题为导向。而且小程序是可升级的，它伴随着微信版本的升级而升级，因此，任何的瓶颈都有可商量的余地，开发者觉得有些地方实在不行，可以提，这是中国人自己掌握的技术。
小程序本身不会作为一款商业产品发布，发布小程序这个动作本身不收费，虽然要有发布资格需要付费认证。它更多的是作为一个平台，一个接入层，对接服务，把原本极其笨重的服务轻量化，对于用户而言，感知不到，对于微信本身而言，虽然自身能实现的东西有限，但却依赖这一平台，实现了无限的可能性。微信本身已经越来越重，如果再提供更多服务，几乎是不可能的，相反，小程序的出现，让社交、服务、支付、游戏等等融合一体，可谓是近20年中国互联网创业者的最终梦想。
什么样的产品算优秀？
在香港过十字路口时，红绿灯会响，慢响表示等待，快响表示可以通行。红绿灯不像大陆那么高，给车看，而是矮墩墩的，等的人可以按。一盏红绿灯，红色代表停，绿色代表行，但是如果是有红绿色盲的人呢？所以，红绿灯除了要有颜色状态之外，还要有声音状态，还要有静动的状态。
谈论一个产品是否优秀，是从它的外观考虑？从档次考虑？从价格考虑？还是从实用性考虑？都不是。一款优秀的产品，它的灵魂决定了它的它的用户是否可以热爱它，忘记它，把它融入自己的生活。什么是一款产品的灵魂？是它抱着怎样的价值观，以怎样的形式，为自己的用户服务。
灵魂，它的本质是爱，是仁，是对这世界的期待。它期待这世界变得美好，它期待这世界温柔待它。
一款优秀的产品，当它离开它的设计者的手，它就有了自己的生命。它所传递给用户的，是关爱，是拥抱，是对未来的向往，它就像黑夜里不烈不晃的光，它照亮路人前行。如果问这世界上，怎样的产品算一款优秀的产品，或许，它被注入了创造者最温柔的一面吧。
