实现评论嵌套逻辑很简单：若评论列表排序为时间升序，只要评论逐条加载，无父评论就是根评论，有父评论就插到父评论下即可；排序若为时间降序，评论嵌套也不难，只要反序（reverse）之，就跟升序的无区别了。
限制评论获取数量出现的问题
单篇文章的评论数量过多时，一次性全部加载就会比较慢，一次性加载太多内容体验上也不大好，所以得限制一次性加载的评论数量。
当每次加载限制数量时，按时间升序不会出问题，但在时间降序时，问题就来了，下面以一个例子来说下：
thread
│
├─post 7
│
├─post 4
│ └─post 5
│ └─post 8
│
├─post 2
│
└─post 1
├─post 6
└─post 3
当每次获取评论的数量限制在 3 时：
- 第一次获取的是 6、7、8 楼，其中阿 7 正常加载，而阿 6、阿 8 找不到父评。
- 第二次获取的是 3、4、5 楼，其中阿 4、阿 5 正常加载，阿 3 找不到父评。
- 第三次获取的是 1、2 楼，都是根评论，正常加载。
以上就只有 1、2、4、5、7 是正常加载的，丢了 3 条。
前端解决
在后端不改的前提下，我选择在前端设置一个未加载的数组变量，当找不到父评时便把评论 push 进去，每次加载评论列表时 concat 它。上面例子使用这个方法解决便如下：
loadlist = [6, 7, 8], unload = [6, 8];loadlist = [3, 4, 5, 6, 8], unload = [3, 6];loadlist = [1, 2, 3, 6], unload = [];
注：每次待加载评论数组 loadlist，加载后的未加载数组 unload。
这样的话，评论就都能正常加载完成了，但有个问题，初衷限制每次加载评论数量为 3，这个 3 在此并没法体现出来，因为第一次加载显示 1 条，第二次显示 3 条，第三次显示 4 条。原本应该的 332 变成 134 了。
后端解决
在前端不改的前提下，后端最好的解决方法就是每次返回都能正常加载的评论数据，按上面的例子，应该返回的数据是：
- 第一次 4、5、7
- 第二次 1、2、8
- 第三次 3、6
后端要处理的感觉就挺多，可以先获取所有的评论[1]，再根据有没父评等，并不简单的排序，还要处理需要传的参数。感觉比较麻烦且不大合理，我就没去折腾。
前端 + 后端解决
另一种妥协的解决方法是结合前后端，后端一次性返回所有评论数据，再由前端去处理每次的显示。前端变成一次获取，多次加载，前端代码会多一些。
综合以上的解决方法，最终选择比较简单的第一种方法解决，虽然例子看起来出入很大，但实际上应用起来。若限制每次加载的评论数为 50，每次加载多几条少几条，在观感上没啥区别。
直至前几天，和 @W_Z_C 讨论这个问题（看不到点此）：
之后，我就真去看看，到底 Disqus 原生评论框是怎么解决这个问题的。
原生评论框每次获取的评论数量是正常的，限制多少就是多少。再看请求，发现评论框用的 API 与我自己用的（threads/listPosts 或 posts/list）竟然不一样，它是使用 threads/listPostsThreaded，Disqus API 文档并没有这个接口的有关说明。看情况，使用这个就应该可以很完美地解决上面所遇到的问题。
经测试，threads/listPostsThreaded的权限跟在 API 文档里有的，并无区别。
不过这里有个问题，Disqus 原生评论框，无论如何都是时间降序排序。我想要的是：无父评的按时间倒序，有父评的就是按时间正序，即上面例子中，3 和 6 位置倒过来，比较符合阅读习惯。
参考资料
本文历史
- 2017 年 08 月 06 日 完成初稿