杨峰的个人博客 – Michael Young's Personal website

为什么执行npm install会更新package-lock.json？

你是否也有疑惑，为什么介入新项目初始化的时候，执行npm install安装依赖，项目的package-lock.json有时候会更新？package-lock.json就是用来固定依赖版本的，按理说依赖的版本都固定了，又没有安装新的依赖就不应该改变的，这是为什么？如果你也有这样的疑问，那么接下来可以进一步跟随我去了解npm install的模块安装机制。当然需要明确一下，这里提到的npm版本version 5及其之后的版本，因为在此之前，还未有package-lock.json之类的配置文件。

npm install（不带参数）安装机制

确定首层依赖

先检查package.json，通过dependencies和devDependencies属性中直接指定的模块。

构建依赖树

确定首层依赖后，会去构建依赖树。这是一个递归的过程，工程本身是整棵依赖树的根节点，每个首层依赖模块都是根节点下面的一棵子树，npm 会开启多进程从每个首层依赖模块开始逐步寻找更深层级的节点，形成依赖树。每个节点在递归的过程中会去确定节点模块的信息，比如版本、下载地址、压缩包地址等。

版本的确定机制：

package.json 中往往是 semantic version（semver，语义化版本）。此时如果版本描述文件（npm-shrinkwrap.json 或 package-lock.json或yarn.lock）中有该模块信息直接拿即可，如果没有则从远程仓库获取。如 packaeg.json 中某个包的版本是 ^1.0.0，npm 就会去仓库中获取符合 1.x.x 形式的最新版本。

依赖树扁平化

上一步得到的依赖树，一般是包含很多重复模块的，比如A模块依赖了moment，B模块也依赖了moment，npm在npm3之后进行了优化，不在严格按照依赖树来进行安装，因为这个过程会浪费大量资源和时间。做法就是对这颗树进行扁平化处理。即简单说来，它会遍历所有节点，逐个将模块放在根节点下面，也就是 node_modules 的第一层。当发现有重复模块时，则将其丢弃。

比如 node_modules 下 A 模块依赖 moment@^1.0.0，B 模块依赖 moment@^1.1.0，则 ^1.1.0 为兼容版本。

而当 A 模块依赖 moment@^2.0.0，B 模块依赖 moment@^1.1.0，则依据 semver 的规则，二者不存在兼容版本。会将一个版本放在 node_modules 中，另一个仍保留在依赖树里。

举个例子，假设一个依赖树原本是这样：

node_modules

— moduleA

—- moment@version1

— moduleB

—- moment@version2

假设 version1 和 version2 是兼容版本，则经过 扁平化 会成为下面的形式：

node_modules

— moduleA

— moduleB

— moment（保留的版本为兼容版本）

假设 version1 和 version2 为非兼容版本，则后面的版本保留在依赖树中：

node_modules

— moduleA

— moment@version1

— moduleB

—- moment@version2

获取依赖树确定的模块

先会通过压缩包地址去判断是否在缓存中存在该版本模块，如果有，就直接拿过来，如果没有，就回去远程仓库下载，下载完后放入缓存，并解压放到node_modules目录中，最后会去新增或者更新lock文件。

回答文章刚开始提出的问题

根据上面构建依赖树的过程，即npm install并不是完全按照lock文件去安装依赖的，是先通过package.json递归创建依赖，然后再看lock中对应的模块固定的版本是否符合semver规则，符合就直接确认版本安装，不符合就会按照package.json的指定的semver规则去仓库拉最新的版本信息并更新lock文件，外部条件不变的情况下（npm版本、上次构建代码等），理论上依赖版本不会发生变化，也就是lock不应该出现更新才对。那么究竟是什么导致了日常中我们感知到的lock变化了呢？

先明确一个机制：

## package.json
"dependencies": {  
  "core-js": "~3.4.5"  
}
## package-lock.json
"dependencies": {  
  "core-js": {  
    "version": "3.4.7",  
    "resolved": "https://registry.npm.taobao.org/core-js/download/core-js-3.4.7.tgz",  
    "integrity": "sha1-PdplYR2VaZtet3QupFHqBS03qmU="  
  }  
}

如上示例代码，依赖的是core-js ~3.4.5, 锁定的是3.4.7。
你把package.json里 core-js 的依赖改成 ~3.4.6 , ~3.4.7，重新安装都不会使 package-lock.json变化， 因为lock文件里面保存的版本比package文件里面的大。但是如果你把package.json文件里面的版本直接改成 “core-js”: “~3.4.8”, 这就比lock文件里面的版本要高了，需要重新下载最新的，会下载符合3.5.x 的最新版。同时更新lock文件。

上面这种情况属于小概率事件，但也不是不会发生的。即手动改了package.json的某个依赖的版本，但是没有去安装和自动更新lock文件，就提交上去了，那么你接手初始化项目，就可能出现lock文件更新的情况。

另外根据实践，还有一种可能，就是有些公司内部有自己的npm镜像，类似cnpm，使用这种类似cnpm install来安装依赖，一般不会更新lock文件，如果团队没统一安装依赖命令，有的用npm install 有的用类似cnpm install，package.json和lock的差异性就会增加，当你使用npm install时，就有可能会更新lock文件。

另外，最大可能的一种情况是大家使用的npm版本不一致，版本不同，那么组织生成lock文件的逻辑可能不同，就可能导致lock文件更新。

npm ci

之所以提这个命令，是因为开篇的那个问题，其实有一层含义就是提问者想要通过lock固定下来的版本安装工程，不想有任何版本变化，保持绝对一致。那么npm ci就是为此而生的。这个命令会完全按照工程的lock描述文件去安装依赖。要注意的是，当lock文件的描述版本不满足package.json依赖指定到semver规则时，会报错退出，并不会往下执行或者去更新lock文件。

首先，不管用什么框架写的组件，在接入另外一个框架时，需要一个包裹组件来完成，而这个包裹组件必须是使用当前被接入项目所使用的框架编写。感觉有点绕？那举个栗子：比如接入的项目是用react写的，那这个包裹组件必须是react编写的。

然后，再来看，这个包裹组件一般需要处理哪些问题，才能衔接2个不同的框架。

以vue业务组件接入react项目为例

首先，vue组件依赖vue，首先确保包裹组件初始化，需要有vue库，如果没有，需要进行异步加载，加载完毕，再进行vue初始化，挂载该vue业务组件到vue实例上。

其次，核心也在于此，如何将react包裹组件接收的参数传给vue组件。熟悉react和vue的api的知道，react的props参数都是一种写法，不同的是参数的类型。vue的props参数写法主要分2类，一类是bind（绑定），一类是on（监听事件）。v-on支持events以对象的形式传入，因此，包裹组件初始化，只需要将事件类的props拎出来，通过指令v-on传入vue组件。（初始化配置项：el, data, components, template）。

最后，记得处理props更新和组件卸载的情况即可。

 initVueInst = () => {
    this.vueInst = new Vue({
      el: this.domRef.current,
      data: {
        props: {...this.props},
        events: this.getEvents(this.props)
      },
      components: {
        Container
      },
      template: `<Container v-bind="props" v-on='events' />`,
    });
  }

那么同理，react写的业务组件如何接入vue项目中呢？

核心是vue组件具备的vm.$listeners和vm.$attrs接口。通过这2个接口，就可以把vue组件上的事件和属性，都给到react组件上。实现透传。这里在vue项目中，一般不能使用jsx语法，这个时候就需要使用react的api，React.createElement来替代jsx。

这种方式的弊端

暂时对于组件传children的情况，适配不了，需要有个转换过程，比较复杂。具体来说，react的chidren和vue的slots，他们的数据结构是不同的，不能直接跨框架使用。

taro是什么

引用官方的一句话来说明：

Taro 是一套遵循 React 语法规范的 多端开发 解决方案。现如今市面上端的形态多种多样，Web、React-Native、微信小程序等各种端大行其道，当业务同时在不同的端都要求有所表现的时候，针对不同的端编写多套代码的成本显然非常高，这时只编写一套代码就能适配到多端的能力就显得极为重要。使用 Taro，我们只需书写一套代码，再通过 Taro 的编译工具，即可将源代码分别编译出在不同端（微信/百度/支付宝/字节跳动小程序、快应用、H5、React-Native 等）运行的代码。

由于各小程序在api设计层面大体上还是一致的，所以这些端的兼容问题会稍微少点。h5和RN还有快应用的兼容，相对来说应该是比较难处理的。

taro兼容h5的实践

从兼容h5端的实践，总的来说，大问题没有，小问题还是不少的。下面我就来一一说说这些小问题。

1. map组件暂未支持编译到h5端（当前taro最新版本2.0.1）。map组件的缺失对于需要的业务来说，还是比较麻烦的，解决办法有2种。第一，可以自己通过js的开源地图封装，对于能力较强的，可以去官方提个PR；第二，看看能不能从产品上进行阉割；
2. iconfont使用alicdn，在本地dev无法显示。这个部署到服务器就没有问题了。后来查看taro的github上的issue发现，跟dev的机制有关系，具体还说不太清楚。需要在iconfont生成的代码font-face的url，指向alicdn的域名前添加完整的http或https协议（默认的域名前是双斜线（//）开头）。
3. swiper组件在h5端，autoplay到最后一个slide，会停止下来(使用taro版本1.3.25)。查看官方changelog，该问题已经在taro版本2.0.0解决。
4. 写样式需要注意2个问题。一个是单位，前期写css，用了rpx单位的情况。解决办法就是写回px。对于行内写了rpx的，使用Taro.pxTransform方法兼容，行内样式写了rpx，不会生效。另外一个需要注意的是高度使用vh。在部分浏览器，100vh是整个屏幕的高度，而视窗高度是100vh减去地址栏的高度，因此最好使用window.innerHeight来替代100vh的使用。

5. onPageScroll函数的定义如果使用函数表达式定义，在h5端不会执行。解决办法是，使用具名函数定义而非函数表达式。

6. 页面栈没有route属性。

const pages = Taro.getCurrentPages()
pages[0].route // route属性取到的值是undefined

解决办法：查询issue发现已有解决办法，在h5端，route获取方法pages[0][‘vnode’][‘_owner’][‘vnode’][‘props’][‘path’]（注：pages[0]泛指页面栈实例）。

1. picker-view组件不支持h5端编译。可以使用picker或者第三方组件来代替。其中如果要使用picker组件来代替，样式需要通过css覆写来实现。然后picker组件的触发，业务中如果不是picker组件点击显示，兼容的办法是获取到picker组件下的子节点，将这个子节点的虚拟dom获取到，调用click，就可以触发了。对于picker的字节点，最好做css隐藏处理。

2. h5端，navigateBack的delta不能设置超过已有的页面栈数量，设置数值过大，跳转会失败，且不会有任何提示信息。

3. setState传入一个方法的时候，返回的对象不能是传入的prevState对象本身，即有的开发者会在prevState对象上修改属性，然后return，在h5端不会生效。

4. $router的参数跟各小程序端的不一样，可以大致这样兼容，即小程序端的this.$router.params等价于h5端的this.$router。

5. taro的绑定事件阻止冒泡，需要在第一个事件处理函数里处理，如果通过第一个事件处理函数传递event，在下一个函数中处理会不起作用。（实验结果taro版本v1.3.25，支付宝端）。

6. image图片，在h5不支持mode属性，需要自己用background-size兼容实现。

7. webview组件的使用，webview内的h5跟壳之间的通信兼容。webview组件编译到h5端，是使用iframe来实现webview的效果的，通信可以使用js原生的方法postMessage来做，在壳这一侧，没有支持组件属性onMessage来监听内嵌h5的数据传递，需要通过addEventListener对message事件进行监听，同时需要注意的是，message事件会默认触发，因此，在传递信息的时候需要通过一些自定义的字段，来过滤掉不相干的message事件的处理。

小结

taro处理的端很多，虽然具备了一定的成熟度，能够满足一些业务需求，但离完全成熟还有点距离，所以难免在使用过程中会遇到坑，踩坑之旅，需要多点耐心，多调试想办法，祝入坑的朋友，不掉发，斜眼笑:)。

前言

小程序底层是基于webview来实现的，虽然不是什么革命性的全新技术，但是却是影响广泛的技术新应用。它的出现不是凭空出现的，肯定为了解决一些问题。那么没有小程序前的客户端有哪些比较明显的痛点呢？

1. 纯客户端原生渲染的缺点：在动态打包，动态下发，存在一些问题，比如缺乏灵活性。
2. 纯web技术渲染的缺点：在一些有复杂交互的页面上可能会面临一些性能问题，这是因为在 Web 技术中，UI渲染跟 JavaScript 的脚本执行都在一个单线程中执行，这就容易导致一些逻辑任务抢占UI渲染的资源。另外一个问题，是web太灵活，用完即走，用户留存度低。

针对这两个缺点，客户端技术、web技术都有一些新的技术方案出现。而在web技术这个方向，大的方向是对web容器进行增强，赋予web更多性能和能力。目前主流有三类技术比较火：

• 小程序技术
• PWA技术
• phoneGap为代表的套壳并对webview增强的技术

这里主要说说小程序技术，其他两类技术在国外较火，但在国内不温不火，由于主题不是它们，这里不多做介绍了。小程序实现的基本思路是通过分离渲染和逻辑的处理，即将小程序的运行环境分为渲染层和逻辑层，每个页面有单独的webview来渲染，而逻辑是在一个独立的线程运行，避免了web的UI渲染跟javaScript在同一单线程中执行会出现的性能瓶颈的问题，因此他们互不干扰，两个线程只会有一些数据通信。同时，提供大量客户端原生能力的接口，从而充分结合客户端原生技术和web技术的能力，给客户端动态化提供了一个新的技术方案。

一门新技术的诞生，在初期，对开发者而言，都会有那么一段黑暗时期，各家小程序都不例外。进入正题，那些年踩过的支付宝小程序的坑。

支付宝小程序开发的一些痛点

小程序自身不稳定

据不完全统计，我们在开发我司在各家超级APP中的小程序的时候，给官方提过的bug，总和不下于百余枚。其中支付宝小程序占比20%左右，分布主要在以下几个方面：

1. input、text-area等表单组件
2. 覆盖原生组件的cover-view组件
3. 支付宝授权
4. 开发工具

当然，我们遇到这几个方面问题都一一向官方反馈过，也得到了官方的确认，在面临这些问题时，由于修复有个过程，我们通过修改产品交互设计和程序hack等方法，也还算顺利地绕开了一些问题。由于大部分问题官方已经修复，所以具体将bug罗列出来没什么意义。重要的是在面对问题的时候，有化繁为简、追根究底的能力。

调试及测试

调试的问题也是比较棘手的，影响业务开发效率，主要的痛点在以下几个方面：

1. 代理抓包只支持ios，不支持android代理抓包，官方解释：其底层网络库有做限制导致的
2. 开发工具与真机在某些特性上表现不一致
3. 体验版不像其他家小程序那样可以使用调试器

目前这些问题还部分存在，虽然不是致命的，但是作为开发者，还是很希望这方面的能力能更快完善和优化。如果你看到本文已经没有这些问题了，那么恭喜你，如果还存在，也恭喜你，顺利入坑。

发版本

每次发体验版，需要重新设置新发版本为体验版，相比于微信小程序的开发体验（同一个人上传体验版，自动更新，无须重新设置体验版）来说，真的不是一般的苦逼，虽然可以通过尽量降低发布频次，集合更多问题统一发版这个解决方案，但是特别是在一些特定的场景下，需要频繁在体验版测试的时候，每次都需要设置体验版，是极其琐碎的事情。希望以后支付宝小程序能改善这一开发体验。

社区反馈

社区论坛第一版的时候，我觉得反馈问题非常方便，是非常好的。但是在今年（2019）5月份开始将社区改版了，满怀期待的新版本社区，在8月份左右上线了，但是却非常不好用，反馈问题、查找问题现在反而变得不容易了，以前提过的问题，也找不到了。这个实在让人费解。期间还在各种渠道，比如在线客服、钉钉官方技术群等反馈过问题，但是这些渠道反馈的问题毕竟没有可追溯性，不是一种理想的反馈bug的渠道。还是希望继续推进社区论坛的建设，以前反馈的问题，也能搜索到，而不是将其抹去。所以总结下，目前相对比较有效率的反馈方式是支付宝小官方技术钉钉群，群号：23362130，反馈问题前，可以先在社区搜索下问题。如果出现了更便捷的反馈形式，欢迎补充。

资源位跳转，与运营及市场人员的沟通之痛

支付宝小程序提供多种跳转能力，主要分为四类：

• 小程序跳转小程序
• url schema 跳转小程序（h5跳转小程序）
• 小程序跳转支付宝官方页面或小程序
• 小程序跳转小程序插件

运营与市场人员为了给小程序导流，时常会给出触达我们小程序的方法，以及收到别人可触达他们家小程序的方法。而由于支付宝的跳转能力是多种多样的，同时我们自己还有一套配置规则，运营和市场人员常常面对的问题就是，收到各种不一样的跳转方法，但是他们不明白这些方法之间的转换规则，自然当需要把资源位上到我们家小程序时，不知道应该怎么转换。同时，当别人要我们家小程序触达方法时，无法按照对方的规则给出方法。

当我们运营市场人员遇到这个问题，目前都是通过直接跟开发沟通，开发帮忙手动转换来实现这个需求。后续，我们还是会尝试一些解决方法，比如开发一些转换工具，给他们使用。

结语

总的说来，小程序的能力是显而易见的，身在中国应该大家都有深刻的印象。但是小程序目前在各家超级APP的具体应用都有不小的差异，虽然底层技术类似，但是由于各个生态存在的差异性，还是对开发者造成了不小的困扰。目前，业界虽有Uni-app, Taro等这种多端开发框架，来抹平多端的底层差异，但是实践来看，仍然不是那么一帆风顺，坑也不少，同时各家的运营策略是不同的，提供的扩展服务不一而同。同时，引入第三方框架来开发，在获取收益的同时，又引入了一个可能出问题的一环，如此，要同时排查第三方框架、支付宝小程序本身和自身业务写法的问题，增大了开发及调试的难度系数。幸运的是，随着时间的推移，小程序底层会逐渐稳定，同时，目前w3c也在积极朝着制定小程序规范的方向努力，小程序的发展会绽放更多光彩。

直奔主题，我们来看一个情况：

<div>
    <div></div>
    <div></div>
</div>

上面就是描述问题的最简单的结果，一个div中有两个子div，要求是第一个div居左，第二个div居右，位置不能变化，第一个div有可能隐藏。

那么问题来了，如何使用flex来实现这种布局呢？

分析尝试

大家很容易想到，父容器flex, justify-content：space-between不就好了吗? 如果第一个元素不隐藏，那毋庸置疑，但是如果第一个元素隐藏，那么第二个元素会自动跑到左边，这样行不通的哟。我也是想了好一段时间，都没想到最好的方案。

margin在flex布局中的力量

最终在知乎上找到了同类型的问题，如何解决前端的flex流动布局中的单个子元素位置？。margin在flex布局中，子元素margin为auto的时候，伸缩包含块剩余的空间将会分配到flex-item的外边距margin上，那这个问题的答案就可以对第二个flex-item添加margin-left: auto来完美解决。同时，这个也很完美的解决了当flex容器下有三个子元素时，要求两个元素居左一个元素居右的这种情况。就不用对两个元素这边再加一个flex容器包裹了。简直不要太完美。

结语

在网上看到的绝大多数flex教程都没有提到过关于margin在flex布局中的应用，这也是此文的意义，希望能帮助到大家，同时希望大家更深入或者找到第一手资料学习。不过大家也许和我一样懒，那我们就多百度咯，毕竟第一手资料读起来不是一般的难受。苦笑。

目前的人类发展阶段，人机交互主要集中在电脑，而与电脑的交互主要有两种，一种命令行，另一种就是UI(user interface)可视化界面。可视化界面具有交互自然的属性，所以更为受大众欢迎，但是不得不说，它受欢迎程度以后会逐渐被语音交互甚至更高级别的人工智能交互所替代，因为以后的交互的发展趋势是趋近于更为自然。貌似扯远了，回到当下，在可视化界面里，点击的交互占了绝大部分，不管是pc的鼠标还是移动端的手机点击。不难想象，这种点击交互的反馈，对我们对这款设备或应用的评价有直接作用。好吧，我发现貌似起高了，我主要想思考的领域没这么广，其实通俗来说就是你点击了，让你知道你的点击的确发生了的反馈, 而且我思考的领域是web前端技术。

在css里，对于点击有active伪类可以响应点击，响应点击后，据我总结，我们主要有5种方式来反馈。

1. 使用背景色变化来响应。目前应用比较广泛，比如按钮、列表等模块；
2. 字体颜色变化。
3. 区域透明度变化。
4. 设置filter滤镜，来改变区域明暗度，色值等。
5. 动效，不多说。

有冲动总结这个是因为自己长期使用macOS和IOS系统，发现在这些系统下的应用，在点击打开时的反馈是使图标变暗，而我在web中，没有实现过这种效果，于是很好奇。在以往，我们的web交互反馈类似的效果，是改变某一区域的背景色来使用户感知。但这样有一个缺陷，就是你不得不对每种颜色去设置点击响应色彩，比如红色，点击反馈你需要设置深红色。很幸运，思考进入状态了，一不小心就抓住了本质，就是一个滤镜功能，才想起css拥有强大的filter样式。但是很不巧，经过www.caniuse.com查询，filter兼容性，IE完全不支持，不管是IE的PC版还是Mobile版。如果你是在移动端，且不考虑IE mobile,那么使用这个属性没有太大问题的，PC如果兼容需要纳入IE, 那么很不幸，这么fancy的样式，你是用不了。

1. 环境搭建及开发调试

• 开发需要安装一个npm包hap-toolkit来生成初始化项目，类似vue-cli;
• 移动端调试器安装，需要andorid手机，去官网资料中心下载apk；
• 项目初始化后，使用npm run watch以及npm run server，通过快应用调试器扫码进入，就可以hot reload了，开发体验不会太差；
• 项目初始化出的模板，从package.json依赖来看，webpack需要升级，太老旧，是1.x的版本；
• 使用vConsole来作为调试控制台，无法安装到快应用中；调试使用快应用调试器提供的调试吧(需要在manifest开启日志，默认off)，它是直接打开默认浏览器，然后接着玩儿；

2. 项目配置信息

• 路由在这里配置；
• 页面级别的信息如页面标题以及标题颜色、标题背景灯，也在这里配置；
• 应用基本信息； 3.框架

大体上

• 写法跟vue类似；
• 生命周期跟微信小程序类似；
• 页面级别的数据在private对象中，类似小程序的data对象；但是调用又跟vue类似，private的数据都挂载在this实例上，不像小程序的data数据是挂载在this实例的data对象上；
• 路由参数传递，两种方式分别是a链接的query和router模块params参数传递,参数接受有两种方式，一种是protected对象，一种是public对象，他们的区别是protected是应用内部参数传递，public负责接收应用外部的参数传递；
• 数据量大的时候，可以用$app实例上的$data来传递参数;
• 数据请求可以使用快应用提供的@system.fetch模块
• 现在app.ux中还不支持公用样式（官方：加了的话，担心性能会变差） 模板
• 文字一定要放在text中，否则不显示（坑）；
• 不支持单位vw,vh；

逻辑

• dom事件模型在快应用中不适用；

css样式( 由于快应用最终效果是native不是h5，用的是css的子集，坑较多)

• css样式不需要写兼容，已经默认集成, 写兼容还可能会报错，默认border-box盒模型，不支持content-box和box-sizing；
• 没有块元素、行内元素的模型；
• css样式中的颜色值只严格支持16进制，不能使用缩写，不能使用语义颜色（还有这种操作，无语）；
• css样式中background只设置颜色的话，需要使用background-color，否则报错；
• 不支持相对定位和绝对定位，支持固定定位；
• 不支持float布局；
• 不支持overflow属性；
• 不支持伪元素选择器，如::before, ::after；
• flex属性不支持缩写，如flex: 1 0 auto；是不支持的，只能单独写flex的属性；
• 不支持样式中使用!important；
• 不支持vertical-align属性；
• 框架目前仅支持长度单位px和%, 当然不支持单位vw,vh；

4.组件

• 自定义组件的引入方式是在模板使用import标签引入；

5.接口

• 接口模块使用，需要在manifest.json中声明（特别是使用web组件时，需要声明，单无需引入模块）；
• 推送模块暂时还未支持（截止20180629）；
• 快应用限制唤起其他app的能力（https://bbs.quickapp.cn/forum.php?mod=viewthread&tid=282&highlight=webview）；

6.发布部署

• 需要在项目中的sign文件夹下添加release签名，然后npm run release，会生成有release签名的工程包，这个包就可以用于部署;
• 部署是需要申请一个快应用的账号，通过后台上传相关项目资料；
• 上传包的时候命名规则与app一致，版本管理要注意，快应用后台会检测versionCode，每次发布需要比上次发布的versionCode大；

后续会持续补充…