@jinx930621 #15 嗯，level4 这个已经包含了乡镇区划数据；至于乡镇这级的坐标和边界就没有采集，也是没有找到数据源，百度和高德都没有提供

@AlexMeng 我用的 SQL Server 里面查询有空间结果，可以直接看
https://ww1.sinaimg.cn/large/007i4MEmgy1g2490abtlgj30rw0f0dj2.jpg

@aleung 比百度的精确，百度抓取完数据才 20m，高德的 130m，边界细腻不少

收藏和回复不成比例呀，帖子沉的快

[占个楼提个问] ：

好奇大家本地和生产服务器上的数据库结构存在差异时是怎么处理?

我一直是一个表一个表手工对，累死个人

比如：开发了个把月，积累了一定量的数据库结构变化，要上线的时候，该如何把本地的结构同步到线上生产服务器上，还能保证不能遗漏？

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

还有一个一直没搞明白的问题，新旧版本都用到的同一个表有改动，并且这个改动不兼容老版本，感觉升级过程中都要暂停服务才行，那么还怎么进行灰度发布，或者从头到尾的流程就是错的？

@liuxu
@9hills
@mmdsun
@allanzhuo
@shoaly
@janxin
@mandy0119
@agoodob
@blakejia
@neoblackcap
@luozic
@rayingecho

除了优酷、Adobe，还出现个 GeekedIn，完全没印象啊

@xustrive 厉害

@mgrddsj #20 我这切换标签、打开控制台+手机模拟 也没用，目前只发现 #14 楼的有用

@taolu #14 还真是，可以恢复了，就是滚轮这个键有点硬，哈哈，搞定

@zhyl 尽量不要用后瞻，难移植

参考我早上发的 /t/552813，前瞻匹配部分和我以前写法一样，是不会有效果的。另外记录一下：刚才发了一篇吐槽 github 的被水深火热了。。现在被关小黑屋中

@binux 嗯，原来如此呀，分解一下豁然开朗，哈哈

意思就是前瞻只能作用于+贪婪匹配到的最后一个字符，并不能阻止+对最后一个字符之前的所有字符进行贪婪匹配。

/(\d+)(?!\.1)/.exec("123.141") 目测是这样的：
> 123：\d+贪婪匹配到.为止
> 12：发现 123.1 不符合(?!\.1)，后退一位
> 没有表达式了，返回 12

/(.+)(?!\.1)/.exec("123.141") 目测是这样的：
> 123.141：.+贪婪匹配到结尾
> 123.141 : 符合(?!\.1)
> 没有表达式了，返回 123.141

/(.(?!\.1))+/.exec("123.141") 目测是这样的：
> 1：.匹配到新的一位
> 1：123 符合(?!\.1)
> 12：.匹配到新的一位
> 12：123.符合(?!\.1)
> 123：.匹配到新的一位
> 12：发现 123.1 不符合(?!\.1)，后退一位，并退出循环
> 没有表达式了，返回 12

如果要对每个字符进行前瞻检查，唯有最后一种写法比较好理解。

#8 咦，微博图床 403 了。。。

https://ww1.sinaimg.cn/large/007i4MEmgy1g1uyojwd3bj309l02lwei.jpg

https://ae01.alicdn.com/kf/HTB1eTOfP4YaK1RjSZFnq6y80pXaF.jpg

@binux 还是不太明白，第一个分组的确是捕获到了`abcde`呀，https://ww1.sinaimg.cn/large/007i4MEmgy1g1uyojwd3bj309l02lwei.jpg

照着你的思路找到 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions 的解释中有个例子：
> >>>>>
Matches 'x' only if 'x' is not followed by 'y'. This is called a negated lookahead.

For example, /\d+(?!\.)/ matches a number only if it is not followed by a decimal point. The regular expression /\d+(?!\.)/.exec("3.141") matches '141' but not '3.141'.
> >>>>>

发现一个现象：

符合预期：/(\d+)(?!\.1)/.exec("123.141")
符合预期：/([^.]+)(?!\.1)/.exec("123.141")
无效：/(.+)(?!\.1)/.exec("123.141")

难以理解，最后一个就是我的写法，咳。。。

@binux 还是不明白，第一个分组捕获到 abcde，预期想要是 abc，前瞻不会和前面的+、*、{}起作用吗？

又发现另一种有效写法：
/<(?!.+def).+>/.exec("<abcdefzzz>\n<abczzz>")

可能是结尾的.+导致的不能匹配，但这样写还是不行：
/<.+(?!def)zzz>/.exec("<abcdefzzz>\n<abczzz>")

#7 username ? 唯一？ 当我没说

不改数据库，就赶紧跑路吧。或者祈祷第一个同名的人晚点出现，再跑路。