2009 年 04 月

本来对于mysql proxy 0.70的release是仅仅当成一个新闻来报道的。结果，老王却写了一篇教你如何配置的文章，你说我是转好呢还是不转好呢？
上午我刚写，人家老王下午就来配置，你说我不转，对得起人家伐？
所以，我只好辛苦一点，，转载一下喽。。

感谢老王

原文：http://hi.baidu.com/thinkinginlamp/blog/item/f96559821fbda8aa0cf4d200.html

MySQL-Proxy的二进制版本的安装相对简单，无需多言，下面介绍的是源代码安装：

安装pkg-config：

tar zxvf pkg-config-0.23.tar.gz
cd pkg-config-0.23
./configure
make
make install

确保PKG_CONFIG_PATH环境变量包含了相关的pkg-config配置文件路径：

export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig

安装libevent：

tar zxvf libevent-1.4.10-stable.tar.gz
cd libevent-1.4.10-stable
./configure
make
make install

安装glib：

tar zxvf glib-2.20.0.tar.gz
cd glib-2.20.0
./configure
make
make install

安装lua：

tar zxvf lua-5.1.4.tar.gz
cd lua-5.1.4

如果你的服务器是64位的，这时要调整一下Makefile：vi src/Makefile，在CFLAGS里加上-fPIC，否则会出错：

/usr/bin/ld: /usr/local/lib/liblua.a(lapi.o):
relocation R_X86_64_32 against `luaO_nilobject_' can not be used when making a shared object;
recompile with -fPIC
/usr/local/lib/liblua.a: could not read symbols: Bad value

接下来不用执行常见的configure，直接make：

make linux
make install

安装pkg-config配置文件，以便编译mysql-proxy时能找到lua：

cp etc/lua.pc /usr/local/lib/pkgconfig/lua5.1.pc

如果没有执行此步骤的话，在后面编译安装mysql-proxy的时候，会得到类似下面的错误信息：

Package lua5.1 was not found in the pkg-config search path.
Perhaps you should add the directory containing `lua5.1.pc'
to the PKG_CONFIG_PATH environment variable
No package 'lua5.1' found

安装mysql：

这里介绍的是完整安装mysql，其实你只要安装mysql开发包即可。

tar zxvf mysql-5.1.33.tar.gz
cd tar zxvf mysql-5.1.33
./configure
make
make install
cp support-files/mysql.server /etc/init.d/mysql
chown +x /etc/init.d/mysql
cp support-files/my-[small|medium|large|huge|innodb-heavy-4G].cnf /etc/my.cnf

如果my.cnf里有skip-federated选项，就注释它，否则安装数据库的时候会出现类似下面的错误：
[ERROR] /usr/local/libexec/mysqld: unknown option '--skip-federated'

/usr/local/bin/mysql_install_db --user=mysql
/usr/local/bin/mysqld_safe --user=mysql &

保证系统能找到mysql_config，后面编译mysql-proxy会用到它：

export PATH=$PATH:/usr/local/bin

还要保证系统能找到mysql库文件：

vi /etc/ld.so.conf 加入/usr/local/lib目录

执行：/sbin/ldconfig /etc/ld.so.conf

安装mysql-proxy：

tar zxvf mysql-proxy-0.7.0.tar.gz
cd mysql-proxy-0.7.0
./configure
make
make install

按照官方介绍做好启动脚本/etc/init.d/mysql-proxy和参数脚本/etc/sysconfig/mysql-proxy，并设置：

chmod +x /etc/init.d/mysql-proxy
chkconfig --add mysql-proxy

搞定了，测试一下：/usr/local/sbin/mysql-proxy -V。官方论坛里有很多讨论，可以参阅。

一种新的图片验证方式。。

原文来自：http://www.cnbeta.com/articles/82206.htm

新闻来源:CNET
Internet上一个持久的问题，就是如何屏蔽掉一些自动软件，如自动注册帐户然后发送垃圾邮件或垃圾回复以提高站点的搜索排名。Google一直致力于这方面的研究，已经在尝试新的方法让bot退散。
目前的测试方法被称为Captcha(全自动区分计算机和人类的图灵测试)，新的Captcha方法的原理是，人类通常能区分出图片的哪个方向是朝上的， 而电脑不能。Google发布了一项新的研究成果，提出了一种区分电脑与人类新的测试方法。这种方法要求受验证者旋转给定的图片，使其直立。

怎样才算是直立的？Google的测试依赖于寻找人类容易识别而电脑很难做到的图片。

Captcha目前已经被广泛使用，经常出现的形式是一些人类还能阅读的污损扭曲的字符 。对于这一方面的研究已经有很多，包括识别3D图片以及区分猫和狗。
如下是来自Google的作者Rich Gossweiler, Maryam Kamvar和Shumeet Baluja在他们的论文中对图片取向技术的描述（论文PDF下载）：
这项任务要求对图片常见复杂内容的分析，对于人类而言一般很简单，而对机器则很难。

给定大量的图片库，如网页图片搜索结果，我们使用一个自动方向识别器识别出那些很容易被识别出是直立的图片，然后我们通过社会反馈机制来确定剩余的图片是否直立对于人类而言是易于识别的。

这种Captcha方法和传统的文字识别方法相比具有很多优势：独立于语言、不需要字符输入并且开创了除文字扭曲以外的另一种Captcha生成方法。这种Captcha能快速的实现，并且有着几乎无限的图片来源。

我们进行的大量的实验就这种方法的可行性进行调查，人类在识别的时候具有很高的成功率，而bot的识别率很差。由于不需要文字输入，其用户体验也比文字类Captcha要好。



有些图片的直立方向的识别对人类也很困难。一次500人的测试的结果显示，受试者对左图的直立方向有着很大的分歧，而右图则不然。

最困难的一点是，如何在难易程度上找到一个平衡点。有些图片对于人类而言很难确定方向，而有些图片暗藏着线索（脸、文字、蓝天、绿草）可以让电脑找出直立的方向。

为了解决这个问题，除了向用户提供已知的易于识别的图片以外，也会加入一些新的图片。如果这些图片经常难以被正确识别出直立方向，就会自动从图片库中去除。

研究者喜欢这种方法的部分原因是图片不需要污损或扭曲，不像Google当前使用的文字Captcha。但图片Captcha在bot与网站之间的军备竞赛中，也不能保证一直有效。

“随着图片方向检测系统越来越先进，我们用于筛选图片的方法也跟着升级，以避免将会被机器出来的图片呈现给用户。”研究人员说，”最终也许我们还是要用到图像扭曲。”

mysql proxy 终于有一个release版本了。只是我最近还用不到这个。纯记录一下

这个实现方式有点妖。
原文是用asp.net实现的。我也没有改，因为，json数据的获取在PHP中真是太简单了。拿到数据后json_encode一下就全有了。。

想看的就做个参考吧。我还是觉得妖
这里只是把主要的代码贴出来，不再进行过多的说明，重要的地方以注释的方式进行说明。

<div id="pubDiv" style="background-position: #9999FF; font-size:12px; display:none; z-index:0; overflow:auto; position:absolute; border:#EDEDED 0px solid;background:#EDEDED;"></div>
<script type="text/javascript" language="javascript">
// 注意下面的等号右面，不能是“<%=BuildJson() %>”，因为JSon整体不能是字符串，同时最后也不能加分号：“;”
var strJson = <%=BuildJson() %>

function ShowBdzDiv() {
var dept = document.getElementById("<%=ddlDeptEdit.ClientID %>").value;
// 构建要下拉选择的内容
var strHtml = "<table border=0px cellpadding=0 cellspacing=0 width=120px><tr>";
for (var key in strJson[dept]) {
strHtml += "<tr><td onclick=SetBdz()>" + key + "</td></tr>";
}
strHtml += "</table>";
var oBdz = document.getElementById("<%=txtBdz.ClientID %>");
var oDiv = document.getElementById("pubDiv");
oDiv.innerHTML = strHtml;

// 设置显示的位置，并显示
oDiv.style.top = "99px";
oDiv.style.left = "100px";
oDiv.style.display = "block";

}
// 当点击选择一个内容时
function SetBdz() {
var oBdz = document.getElementById("<%=txtBdz.ClientID %>");
// 把选择内容设置到TextBox上，并隐藏下拉选择项
oBdz.value = event.srcElement.innerText;
HiddenDiv();
}
// 隐藏下拉选择项
function HiddenDiv() {
var oDiv = document.getElementById("pubDiv");
oDiv.style.display = "none";
}
</script>
。。。
<!--这里只有一点要注意：设置AutoCompleteType="Disabled"-->
<asp:TextBox ID="txtBdz" AutoCompleteType="Disabled" onfocus="ShowBdzDiv()" runat="server"></asp:TextBox>

这里要说明的是，这里只实现了下拉选择项的点击选择，不能使用键盘操作。

来自dbanotes的文章，不多介绍了。我很多文章来自于dbanotes和sanotes网站

原文地址：http://www.dbanotes.net/arch/small_site_arch.html
原文如下：

到处都是什么大规模啊，高流量啊，高性能之类的网站架构设计，这类文章一是满足人们好奇心，但看过之后也就看过了，实际收益可能并不大；另外一个副作用是容易让人心潮澎湃，没学走先学跑，在很多条件仍不具备的情况下，过度设计、过度扩展(高德纳大爷也说过，"过早优化是万恶之源")，所以，这里反弹琵琶，讨论一下小规模、低性能、低流量的网站该如何搞法。

如果站点起步阶段可能就是一台机器(或是一台虚拟机，比如 JobsDigg.com )，这个时候，去关注什么数据拆分啊，负载均衡啊，都是没影子的事情。很多大站点的经验绝不能照搬，辩证的参考才是硬道理。

拥抱熟知的技术

动手构建站点的时候，不要到处去问别人该用什么，什么熟悉用什么，如果用自己不擅长的技术手段来写网站，等你写完，黄花菜可能都凉了。所以，有现成 的软件组件可用，就不要自己重新发明轮子。人家说 Python 牛，但自己只懂 PHP ，那就 PHP 好了，如果熟悉 .net ?，那也不错。用烂技术不是丢人的事情，把好技术用烂才丢人。

架构层次清晰化

起步的阶段应该清楚的确定下来架构的层次。如果都搅和在一起，业务一旦扩增开来，如果原有的一堆东西拆不开就是非常痛苦的事情。

Web Server <--> (AppServer)<-->Cache(eg. Memcached)<-->DB

层次清晰化的一个体现是(以 LAMP 架构为例)：即使只有一台机器，也应该起个 Memcached 的实例，效果的确非常好--一般人儿我不告诉他...不要把什么都压到 DB 上，DB 一旦 I/O 压力走到磁盘上，问题要暴露出来是很快的。没错，DB 本身也会利用自己的 Cache，但 DB 的Cache 和 Memcached 设计出发点毕竟不一样。

数据冗余? 有必要

很多人并不是数据库设计专家，如果应用要自己设计表结构什么的，基本都是临时抱佛脚，但三个范式很多人倒是记得牢，这是大多数小型 Web 站点遇到的一个头疼事儿，一个小小的应用搞了几十个表... 忘掉范式这个玩意儿! 记住，尽可能的冗余数据，你在数据层陷入的时间越多，你在产品上投入的就会越少。用户更关心的是产品的设计。

前端优化很重要

因为流量低，访客可能也不多，这时候值得注意的是页面不要太大，多数流量低的站点吃亏就在于一个页面动辄几兆(我前两天看到一个Startup的首页有4M之大,可谓惊人)，用户看个页面半分钟都打不开，你说咋发展? 先把基本的条件满足，再去研究前端优化。

功能增加要谨慎

不是有个 80/20 原则么? 把最重要的精力放在最能给你带来商业价值的地方。有些花里胡哨的功能带来很大的开销，反而收效甚微。记住，小站点，最有价值的是业务模式，而不是你的技术有多牛。技术是为业务服务的，不要炫技。

有些网站不停的添加功能，恰恰是把这些新功能变成了压死自己的稻草。

从开始考虑性能

这一点是可选的，但也重要。设计应用的时候在开始就应考虑 Profile 这件事情。一套应用能否在后期进行有效优化和扩展，很大的程度限制在是否有比较合适的 Profile 机制上。需要补充的是，对性能的考虑必然要把有关的历史数据考虑进来。另请参见网站运维之道的容量规划以及其它小帖子。

好架构不是设计出来的

这是最后要补充的一点。好的架构和最初的设计有关系，但最重要的是发展中的演化：

发展-->发现问题-->反馈-->解决问题(执行力)--> 改进->进化到下一阶段--新问题出现(循环)

有些站点到了某个阶段停足不前，可能卡在执行力这个地方，来自用户的反馈意见上来了之后，没有驱动力去做改进。最后也是死猪不怕开水烫了。

这篇文章有浓重的山寨风格，所以，你不要太认真。如果在用短平快的方式构建某些山寨网站的话，可参考其中对你有益的点，不赞同的地方可以直接忽视掉，就没必要费力留言进行争论了。

--EOF--

1、获取编辑器中HTML内容
function getEditorHTMLContents(EditorName)
{
var oEditor = FCKeditorAPI.GetInstance(EditorName);
return(oEditor.GetXHTML(true));
}
2、获取编辑器中文字内容（无html代码）
function getEditorTextContents(EditorName)
{
var oEditor = FCKeditorAPI.GetInstance(EditorName);
return(oEditor.EditorDocument.body.innerText);
}
3、设置编辑器中内容
function SetEditorContents(EditorName, ContentStr)
{
var oEditor = FCKeditorAPI.GetInstance(EditorName) ;
oEditor.SetHTML(ContentStr) ;
}

function InsertHTML(html) {
var oEditor = FCKeditorAPI.GetInstance("editor") ;
if (oEditor.EditMode == FCK_EDITMODE_WYSIWYG ) {
oEditor.InsertHtml(html) ;
}else
alert( "FCK必须处于WYSIWYG模式!" ) ;
}

虽然在用LINUX，但其实对于它的安全，并不是很了解，所以，看到有这样的文章时，还是会记录一下。
原文：http://item.feedsky.com/~feedsky/phpv/~1232318/202448855/1235221/1/item.html
来自：PHP5研究室

俗称“脚本小鬼”的家伙是属于那种很糟糕的黑客，因为基本上他们中的许多和大多数人都是如此的没有技巧。可以这样说，如果你安装了所有正确的补丁，拥有经 过测试的防火墙，并且在多个级别都激活了先进的入侵检测系统，那么只有在一种情况下你才会被黑，那就是，你太懒了以至没去做该做的事情，例如，安装 BIND的最新补丁。

一不留神而被黑确实让人感到为难，更严重的是某些脚本小鬼还会下载一些众所周知的“root kits”或者流行的刺探工具，这些都占用了你的CPU，存储器，数据和带宽。这些坏人是从那里开始着手的呢?这就要从root kit开始说起。

一个root kit其实就是一个软件包，黑客利用它来提供给自己对你的机器具有root级别的访问权限。一旦这个黑客能够以root的身份访问你的机器，一切都完了。 唯一可以做就是用最快的效率备份你的数据，清理硬盘，然后重新安装操作系统。无论如何，一旦你的机器被某人接管了要想恢复并不是一件轻而易举的事情。

你能信任你的ps命令吗?

找出root kit的首个窍门是运行ps命令。有可能对你来说一切都看来很正常。图示是一个ps命令输出的例子。真正的问题是，“真的一切都正常吗?”黑客常用的一个 诡计就是把ps命令替换掉，而这个替换上的ps将不会显示那些正在你的机器上运行的非法程序。为了测试个，应该检查你的ps文件的大小，它通常位于 /bin/ps。在我们的Linux机器里它大概有60kB。我最近遇到一个被root kit替换的ps程序，这个东西只有大约12kB的大小。

另一个明显的骗局是把root的命令历史记录文件链接到/dev/null。这个命令历史记录文件是用来跟踪和记录一个用户在登录上一台Linux机器 后所用过的命令的。黑客们把你的历史纪录文件重定向到/dev/null的目的在于使你不能看到他们曾经输入过的命令。

你可以通过在 shell提示符下敲入history来访问你的历史记录文件。假如你发现自己正在使用history命令，而它并没有出现在之前使用过的命令列表里，你 要看一看你的~/.bash_history 文件。假如这个文件是空的，就执行一个ls -l ~/.bash_history命令。在你执行了上述的命令后你将看到类似以下的输出：

-rw------- 1 jd jd 13829 Oct 10 17:06 /home/jd/.bash_history

又或者，你可能会看到类似以下的输出：

lrwxrwxrwx 1 jd jd 9 Oct 10 19:40 /home/jd/.bash_history -> /dev/null

假如你看到的是第二种，就表明这个 .bash_history 文件已经被重定向到/dev/null。这是一个致命的信息，现在就立即把你的机器从Internet上断掉，尽可能备份你的数据，并且开始重新安装系统。

寻找未知的用户账号

在你打算对你的Linux机器做一次检测的时候，首先检查是否有未知的用户账号无疑是明智的。在下一次你登录到你的Linux机器时，敲入以下的命令：

grep :x:0: /etc/passwd

只有一行，我再强调一遍，在一个标准的Linux安装里，grep命令应该只返回一行，类似以下：

root:x:0:0:root:/root:/bin/bash

假如在敲入之前的grep命令后你的系统返回的结果不止一行，那可能就有问题了。应该只有一个用户的UID为0，而如果grep命令的返回结果超过一行，那就表示不止一个用户。

认真来说，虽然对于发现黑客行为，以上都是一些很好的基本方法。但这些技巧本身并不能构成足够的安全性，而且其深度和广度和在文章头提到的入侵检测系统比起来也差得远。

其实，开心网，我也就上去一段时间就不怎么玩了，主要还是我老婆在玩。
不习惯那种氛围吧？不过自己也会偶尔上去做做投票啥的，里面的停车位、买奴隶、咬人、种田啥的确实没有什么好玩的。

买房？纯粹是YY嘛。现实中买不起房只能去网上自己安慰一下自己？打工？王老吉分店总经理又怎么样？还是在YY。种田吧，还要担心被偷，停车吧还要被贴牌。车也买不起。所以。。。对这类YY型游戏，我是兴趣不大的。

当然做做投票，还是有点乐趣的，SNS嘛。传说中的六格理论（名字可能记错）？每6个人你就会认识一个人。找找朋友也还是有机会的。

下面贴上某位朋友的文章，里面介绍的两篇原文写的不错，挺长。我也全部看完了。作者截出来的这段很有意思。。。

原文：http://shiningray.cn/tou-cai.html

今天读到两篇文章，《这么开心》与和菜头的《韩流来袭》。这两篇应该合起来看。

前一篇文章作者分析了kaixin001的花园组件的设定，这种设定是完全鼓励偷窃而非劳作的——相比之下，开心农场的设定就要更有“道德”一些，开心农场中任何植物不能被完全偷光。

和菜头则通过韩国奇怪的搜索引擎（各家独立的庞大门户，和局限于自己的引擎），说出了这种模式的问题：

中国人有着悠久的传统，每天在书包里带一块砖，用饭盒打一盒单位的水泥回家，经过数月之功，修建一个自己家的小厨房。对于 分享和探索，中国人没有多少兴趣。但是，对于像个搬仓鼠一样把外面的资源弄回自己的小家，却人人都有浓厚的兴趣。开心网上最火热的两款游戏是争车位和偷 菜，可以从一个侧面印证这一点。

对于这种分享上的文化差异，我希望只是设计师的设定问题。

myisam如果经常insert,update,delete会产生很多的碎片，而且因为表类型的关系，其实它如果使用不当，也会有损坏的情况发生，一般情况下，可以使用repair table来进行修复。老王说，尽量使用 myisamchk来进行修复，因为这是命令行下的，所以，我没有用过。命令行下，我用的也是repair table。
所以，我转载了老王的这篇博客，写完后，老王又来了一篇TableCache设置过小造成MyISAM频繁损坏，看来，myisam表之所以容易损坏，和tablecache的设置还是有关的。

修复表的原文如下：
当我们用PHPMyAdmin浏览数据库时，有时候会发现某些MyISAM表的Collation项显示为“in use”，这多半说明此表已经损坏。即便是没有出现“in use”字样，也不能就此说明表是完好无损的，熟悉检查及修复方法是必须的。

通过语句：

检查表使用CHECK TABLE语句，如下：

CHECK TABLE tbl_name [, tbl_name] ... [option] ...
option = {FOR UPGRADE | QUICK | FAST | MEDIUM | EXTENDED | CHANGED}

修复表使用REPAIR TABLE语句，如下：

REPAIR [NO_WRITE_TO_BINLOG | LOCAL] TABLE
tbl_name [, tbl_name] ...
[QUICK] [EXTENDED] [USE_FRM]

通过命令：

检查修复表可以使用myisamchk命令：

myisamchk [options] tbl_name ...

如果没有指定参数，那么myisamchk命令缺省执行的就是检查动作。若是要修复表，可以使用-r或-o参数，应该优先使用-r修复，不行的话再使用-o修复。此外，在修复前应该使用FLUSH TABLES刷新缓存，并关闭数据库服务器或者锁定所有的待修复表，以确保在修复过程中不会有其他写操作。

自动修复：

在my.cnf配置文件中的mysqld部分设定myisam-recover参数，当服务启动时可以自动修复有问题的表（速度快慢视数据多少）：

[mysqld]
myisam-recover [= options]

参数有DEFAULT，BACKUP，FORCE，QUICK，可以设定为BACKUP,FORCE，万万不可单独设置成FORCE，否则数据文件丢了都没处哭去。


应该尽量使用myisamchk命令去修复，不行再用repair语句去修复（慢），还不行就参考下面链接。

参考文档：How to Repair Tables
而对于tablecache的设定，老王建议：如果你比较懒惰，也可以用MySQL Performance Tuning Primer Script来判断参数是否合理

我也来个前言，架构这东西，研究的人越多，我能够做参考的也就越多，哇哈哈哈。不多说，贴copy来的文章，原文见博客园：http://www.cnblogs.com/micronet-lukey/archive/2009/04/14/1435520.html。

当然这个架构和我们传统意义上的WEB架构不太一样，但我想说的是这些问题还是可以作为一定的参考。比如我们在开发的时候，是直接上SVN还是采用传统的目录共享式开发。现在SVN已经成为很多项目开发所必备工具了，但如果我们在部署的时候采用SVN进行分发代码呢？审核关如何过？

程序员->发送到SVN服务器->SVN分发到测试组->测试组分发到正式机

这是一种解决方法，其实也有点象下文的图片。但实际操作中，当然不太会这样操作。不过也差不多是类似的方法。

让我注意的其实是文章的最后一句话。。。

前言：

目前，公司的呼叫中心程序已经在中国的很多城市运行着。由于受到技术和网络环境的限制，这些呼叫中心程序安装实施完毕后，我们都是采取客户先反映问题，然后我们再安排人员时间进行维护。这种被动的维护机制带了很多问题。

目前存在的问题：

一：客户在描述问题的时候，并不能深入到系统的内部，往往只是描述了一个系统报错的现象。由于公司里已经没有当时的运行环境，在公司内很难做到故障重现，也就很难定位到故障的原因。系统维护和bug修补难度很大。

二：呼叫中心的程序日志都是分散存放的。哪台计算机中的程序报错，就到那台电脑中找出错日志。这个过程必须人工干预。有时候，有些报错内容非常致命，但由于公司不能及时获取到这些信息，导致很多问题就像一颗定时炸弹一样无法及时排除。

三：当公司更新了一个版本后，如果不能到现场维护，只能通过远程或者让客户代劳替换新程序。这种更新机制一旦遇到网络中断，或者客户不配合，将给维护工作带来很大障碍。如果由于需求变更较多，需要经常更新版本， 那么面临的问题将很难解决。

解决的措施：

就第一和第二个问题，可以通过改进目前的日志记录方式来解决。通讯服务器接收客户端程序的错误日志。并且把这些日志内容打包成E_Mail邮件，定时发送到公司指定的邮箱中。

就第三个问题，可以通过自动更新服务来解决。维护人员把最新的软件更新包上传到客户端的通讯服务器中。客户端程序监测到有最新的软件更新包，可以自动更新。

解决问题的核心就是在客户那安装一台通讯服务器。这台通讯服务器既要能能够连接到Internet，同时还要和内部的服务器向连接。这台通讯服务器有两个作用：

1：发送各个程序的错误日志到公司的邮件。

2：接收公司上传的程序更新包，并自动通知各个客户端程序更新。

所有的工作都由服务器自动完成。

总结：

任 何一个系统，在现场部署完成，用户正式开始使用后，对于我们开发组来说，那只是万里长征走完了第一步，后期不断地查错，改进，更新，替换也会占用到大量的 人力物力，如果是外省的客户，跑一趟现场还会占用大量的财力。按照现在的技术能力和网络环境，我们完全可以通过技术手段，更高效地对各个系统进行维护。

维护的最高境界是：客户还没有发现问题，我们已经捕捉到bug并在后台悄悄地把程序更新了。