只是突然想写下自己的想法。加油，慢慢来。
首先自己的思路是，先排序，然后同时从最左边和最右边开始，不断使两边的索引向中间移动。
这让我想到了快速排序，快排中partition的思想是，左右开弓，小的数到左边，大的数到右边，最后找到中间值应该在的索引位置。
而我对于这个题的思路是，min + max，如果小于target，那么增大min（因为此时减小max永远不可能达到target），反之就减小max。如果不算排序过程，后面那一步应该是O(n)时间复杂度的吧？
然后是看了大佬的思路link，感谢大佬分享（希望有天我也可以去分享优质内容）。
需要哈希表的知识。
思路：当然低时间复杂度的话，就不能用排序了。我们用一个map来记录前面搜索过的数值和索引。然后很重要的一点是，我是通过两数相加来寻找答案，但是两数相减更精妙，你可以通过计算target和当前值的差值，然后在前面遍历过的元素里面去寻找是否有对应的数值。关键点在于哈希表map。
不明白的地方：对map结构进行查找，可以几乎没有时间复杂度吗？？答案是确实，哈希表的key值查询可以认为是O(1)
可以先学习下其他类似的数据结构 数组：查找O(1)，增删O(n)；线性链表：查找O(n)，增删O(1) 二叉树：平均复杂度均为O(logn)。
牛逼的哈希表来了，没有冲突的情况下，复杂度只有O(1)。以Java中的HashMap为例，后面有时间详细写写它在处理冲突时选择的具体操作。 （学数据结构的时候学过好多操作，当时觉得很抽象，现在看来，还挺牛？）
