池是需要的，可以显著提高性能，使用池时一般叫 release , 不叫 close，代表将连接释放回池，实际上池在一定时间内会保持连接给别的代码使用。
node 使用异步模型，一个连接显然是不够的，假定一个请求使用一个连接，池中有十个连接，此时则可同时对十个并发进行处理，若池中只有一个连接，则只能一个个地处理。
若你只使用不 release，则在若干个请求之后程序不再响应。因之后的连接会一直在等待别的请求 release

@zinan 这个主要是可以搜索，窗口多时比较有用

403 吗，应该是 user agent 的问题。复制外浏览器的 ua 试下

发现年纪大了，果然是跟不上年轻人的思维，谁能翻译一下楼主在讲个啥？

有什么理由不 ssh 进去吗？

至于 validation , 是什么目的的 validation? signature ?

文件大小限制可以通过 content-length 解决, 浏览器会带有这个 header 的。超限直接抛错就行

弄成锁屏界面说更帅了

@geelaw
"所以我说如果 pid < id 且按照 id 升序返回那就不会有问题啊"
第一，即使你的假定可以做到，分页的意义在哪里？第二，你的假定根本不可能做得到，行政区的划分并不是一成不变的，一定会存在 pid > id 的情况：如新区成立， 老的村镇其 pid > id

"为什么有根树的森林就一定要是递归的样式？有根树的森林不可以是符合一个约束的父亲数组存储？"
这里说的不是存储的问题，而是前后端数据结构交换的问题。前端不应关心后端如何存储数据，后端不应关心前端如何展示数据，两者之间通过合理的数据结构进行交流。

A
前端不应关心数据如何存储，既然这是一个树形结构就要返回一个对应的树形结构。后端应保持数据结构的统一表述和抽象隔离。现在是一个表结构，以后是一个文档结构呢？使用产后端分离最大的诉求之一是前端可能有无数个，从种类上分有 spa / mpa / iOS app / android app / 各种平台的 app。若在前端进行递归整理，工作量和维护量会增多。反之，你只要在后端维护一个树形结构，就可以节省很多前端的工作量以及可能出现的 bug。

1. 节省服务器资源的问题不存在，后端必须做 cache，否则只要有某一些前端 /app 调用不合理后端就跨掉？
2. 源数据结构不改页面就不用改？那要看你怎么定义源数据结构这个概念了。是从业务层面上去看这个问题，还是从数据库层面上去理解。
3. 我觉得可以用『去餐厅吃饭』这件事来类比这个事情。对于一个树形结构，直接返回原始底层数组，就相当于餐厅把原材料给你上上来，然后叫你自己拿回家去煮。

以上，你说的三条好处全部站不住脚，这不是后端偷懒的理由。即使你们要按哪端去处理比较方便，也得以『前端会有很多个 app 』这样的前提去考虑，以后端必须做 cache 为前提去考虑，以业务逻辑和关注点分隔的原则去考虑。

再扩展一下话题，若将来你们要集成第三方平台，然后他们的 location id 与你们的 location id 不一致要怎么处理？若『后端只给数据』这个是可以接受的话，然后是要把第三方的 id 也返回给前端，让所有的前端去处理吗？


@geelaw location selection 最多做一个联动选择界面，为什么要分页？分页之后只有一部分的数据，如何正确重建树形结构（如何说某一个 parent 没返回来过，但它的 children 返回了）？


@binux 有意思，表应如何设计？

@qiqico threshold

插件管理推荐用 vundle，只要同步 vimrc 和 gvimrc。每个机上执行下 PluginInstall 就能统一环境，很方便。
另外，楼上讲的有道理，啰嗦的强类型语言如 java cpp c# 之类还是用 ide 加 vim 插件好些

@firefox12 可以上传到 imgur / sm.ms 或者你自己的 sftp / ftp 服务器。 local 协议配合网络磁盘映射也可以传到本地局域网上的机器。

@kmahyyg 这个是 desktop app ， android 支持不了哇。移动设备上使用这种工具不太常见吧。

@czc2004211 不支持微博图床，若是 MacOS 推荐 iPic ， 支持微博图床

@sobigfish windows 专属问题，试过 libcurl + winssl 编译，是不行的。 ca 是 firefox 官网提供的，你可以自行更换。

@iPhone8 可以放大啊，点一下图片就行了。

@jy02201949 呃，我没做 oauth ，那需要独立服务器啥的。有运营成本

@jy02201949 用的是匿名的 api 。要在你的个人相册看到那得做 oauth 才行的