@liximomo 我做了这方面努力，我想搞个完整复现 demo 出来，所以我去弄了，弄完后 demo 项目缺一点问题都没有（问题 3 所述）。所以意思就是产生问题的源头可能牵扯到项目更大范围我无法控制的地方。我这么一想，我怂了（也许这个行为就是你说的黑暗吧），我可能需要把全部源码搬上去也说不定。 所以内心还是想着自己解决。 你说的对，我也觉得这么做是不对的。 确实我的确是个弟弟和菜鸡

@jorneyr 对对，就是这种问题，感觉特别不好问别人，也不知道该不该问别人，看上去一切都是按照文档走的，但就是出问题，问别人，回答无非都是那些最常见的解法（可能你已经在问之前就已经尝试无数次无果的东西），js 用起来很方便，但是有时候又感觉不好控制，总是冷不丁一个神奇的错误冒出来。

@lscho 但是很奇怪的是我项目很多地方都是一样的风格 都没问题，唯独这里必须要根元素包裹

@libook 谢谢。 我发帖确实感觉在抱怨。 标题其实也提了希望有人开导下，而不是帮我解决问题。 我在发帖后感觉看到大家的回复，觉得受到了一些鼓舞，所以就继续排查问题了。最终虽然不太完美的解决了。不过感觉我的心境好像发生了某种质的变化，这也是一种提升，所以我感觉我昨天的青春并没有浪费而不再感到难受了。谢谢大家

@shintendo 是的, 我认同.

问题解决了,虽然我不知道为啥(写程序以来, 第一次彻底放弃思考了 ,以前的问题我一般都会刨根问底的)

我就改了一个地方,就一切正常了.不会出现唯独 concat 方法不会触发 v-for 更新的问题, 如下

在我主题中说的子组件中其实还套用了另一个组件,叫 new-message, 我在其外围包裹了一个 div 后, v-for 的功能突然就一切正常了, 不会变得稀奇古怪的.

```
<template>
<div>

<p v-for="item in messageItems" :key="item.id">{{item.content}}</p>

<div> <!-- 在此添加一个 div 来包裹 new-message 这个组件, 一切就都正常了 -->
<new-message ref="newMessage" @on-success-valid="handleNewMessage"></new-message>
</div>

</div>
</template>

<script>
export default {

props: {
messageItems: {
type: Array
}
},

//.....

}

</script>

```

---------------

顺便回复下楼上一些好心大佬的回答:

1. 我使用 push 也不会触发更新
2. 我检查了 key 是否重复,随后我故意重复发现 vue 会报错,也证明了我数据应该没有问题
3. 用 this.data = [] this.data = res 这种语法赋值会触发更新, 我已经说了,是唯独 concat 函数去更新不会触发 v-for 的更新

--------------

总结:

第一次对 vue 产生了心理阴影, 也怪我不想看源码(实际上是太菜看的慢,一知半解=不懂, 所以只能不停的测试测试测试)

睡了, 让我自闭会

赚钱不如省钱的路过

是一个标记，下次使用的时候，如果遇到这个标记，就会扩展为默认容量 10

轻吧?

@manecocomph 谢谢建议！你说的一些我还有点没搞懂。今天太晚了，下次有空我再来消化你的建议。感谢回复小白的问题

@mind3x
首先，非常感谢您的回答，让我见识匪浅！我也对自己草率的测试和草率的理解表示歉意！同时也对同步，锁这方面的技术研究感觉涉及范围之广，考虑要素之多而有点望而却步！（只负责写过小项目 crud 的 coder 再次感受到了 coder 与 coder 之间的差距！）

下面是我的一些小总结，也算是对自己的提问的初衷做一个交代。

假设有一个计数器，由于在计算机中，线程是可以同时“执行“的缘故，所以会容易发生少记一次的问题发生。于是人们想出了[线程同步]，它就像是一个门的锁，可以让线程执行到一个位置的时候停下来等候前一个线程执行完毕。通过这种思想，就可以解决前面发生的少记一次的问题。

但是这种思想带来了一个副作用，那就是使得程序的效率下降了。所以我们在尽可能达到目的的同时。推出了各种锁的实现来弱化这个副作用。目前来看，锁的实现思想有很多，下面是我个人可以 get 到的一些，
1. 最原始的思想，让线程串行，所谓的悲观（？），缺点就是效率不好
2. 基于 1 的优化思想，让读写操作分离处理，不是让全部线程单纯的等待，而是符合一定安全条件的线程可以继续执行代码，比如 RWLock，对于读读读操作可以让他们并行执行，使得当读写比例中读占绝大多数比重的时候，RWLock 的效率是相当高的。这种优化思想的缺点是：优点就是他的缺点，是一种双刃剑，符合一种条件，那么肯定会违背另一个对立面，导致其性能大大降低
3. 基于 CAS （ Compare And Swap ）和原子性的思想，是非堵塞的，故为乐观锁的一种实现方式。它先检查我们读取的 count 的值是否是最新的，如果是最新的，那么进行更新（这整个过程必须符合原子性）。比如 Atomic 类的 compareAndSet 方法，其本身通过 CAS 指令（硬件指令集）达到了原子性，直接从内存中取出数据比较并赋值。如果不是最新的（存在 contention ），则进行第二步操作，这个第二步操作目前我 get 到的有如下三种：

3.1 升级为重量级的悲观锁，缺点可想而知
3.2 再查一次，直到最新为止（本文的 increase2 就是这个思想），缺点是当竞争激烈的时候，在循环上的开销会很大
3.3 不继续查询，在当前线程内存中记录冲突次数（英文貌似叫 delta ），当读取 count 的时候，返回 count+sum(delta)的值，比如 LongAddr 类。这似乎是三种思路里面最好的方法，不过也有缺点就是读取的时候要做相加的额外操作以及多余的空间开销。

那么其实说了这么多，都是在为下面的结论做铺垫：
"使用哪种锁策略是不能随便纸上谈兵的，必须要根据实际情况，根据实际的竞态条件来决定哪种思想更适合，最好是能模拟出实际环境，随后使用 JMH 来做下 microbenchmark ！并且不要小看 synchronized 的实力，其背后到底使用哪种思想去实现锁不是我们非底层实现人员可以随便猜想的，synchronized 作为 java 实现同步的主力军，有自己的努力，综合上来说，synchronized 的性能是非常稳定的，这肯定得益于其背后的优化算法，正如 mind3x 所说的那样！"

@ywcjxf1515 谢谢提醒！我修改了下计时机制！我只计时了自增的耗时！这次结果确实是 CAS 胜利了！ 谢谢解惑！ 测试程序写的不周到导致的结果。请原谅我的无知

希望可以帮忙看下我这个问题，https://www.v2ex.com/t/576609#reply0

从楼主的问题引发出来的后续问题

总结一下：
parallax.js 是个不错的项目，可插拔，移植简单，做到了一定的视差滚动。
不过 https://christmasexperiments.com/about 的效果不是单纯的视差滚动，还带有一定的 3d 立体感（会感觉字体是漂浮在空中的那种感觉）不知道那是怎么实现的

@wunonglin 谢谢回复！你说的应该没错！不过我前端这块不熟所以不敢多言。不过一楼的答案是非常不错的一个实现方案，是我想要的东西！

@ztmqg 感谢，是我想要的可插拔式的 js，非常感谢！