Google退出中国，网管办通知所有媒体Google的新闻只能发新华社通稿。大家都很听话，就可能吧(www.kenengba.com)傲娇脾气，明目张胆：“就不发新华社通稿，爱发啥发啥”。结果它如愿以偿的被关了。

是的，我宁愿站在外面被雨淋，也不愿意蹲在只有我身体1/3高度的屋檐下。

“朝鲜当局于上周在平壤市顺安区的某一射击场，枪决了朴南基。”报道称，朝鲜货改失败后，朝鲜居民对此产生了不满情绪，因此朝鲜将责任推给朴南基，以反革命分子的罪名，予以枪决。
报道还引述消息人士的话说，朝鲜当局给朴南基的罪名是“作为大地主的儿子，潜入革命队伍，蓄意置国家经济于死地”。
朴南基于1月中旬在中央党全部干部出席的“中央党大论争”上，受到了强烈的批评，之后被拘禁，并接受了国家安全保卫部的审讯。

A: 我是大概在06年的3月份加入豆瓣的。当时应该是豆瓣的02号程序员。01号是阿北。现在是任豆瓣的首席架构师。负责豆瓣技术开发的相关工作

Q: 我记得在之前社区中有对豆瓣高并发能力的讨论，豆瓣现在的用户数量以及访问量如何？用了多长 时间达到了现在的水平?

A: 现在的话，我刚才没有上网，不知道现在是不是已经达到了300万用户，如果还没有达到的话，马上就会到了，可能是今天，可能是明天。300万是指我们的注 册用户，另外还有千万级的非注册用户。访问量的话，现在应该是两千万每天。

Q: 如果能达到这样的访问量，确实说明豆瓣高并发的能力是相当强，我想请您从技术这个角度介绍一 下豆瓣网的架构。

A: 这个话题比较大一点，我刚才在演讲的时候，已经表述这方面的问题了。可以这么说，最简单的方法来说，豆瓣网可分割成两大块：一块是前端的Web，也就是用 户在浏览器访问的时候会触发一系列的操作，从数据库拿出数据，渲染成HTML页面反馈给用户，这是前端；另外一块是后端，在豆瓣有一个很强的数据挖掘团 队，每天把用户产生的数据进行分析，进行组合，然后产生出用户推荐，然后放在数据库里面，前端会实时的抓取这些数据显示给用户。

Q: 如果是这样子，要是让你重新设计的话，你会觉得有必要改进里面哪些部分 吗？

A: 豆瓣（架构）设计现在在WEB这一端主要是用这么几种技术：前端是nginx和lighttpd，中间是Quixote的Web框架，后面是MySQL以 及我们自己开发的DoubanDB。这些除了Quixote都是一些比较流行的、尖端的技术。Quixote稍微老一点，如果要重新设计的话，可能会在这 方面做一些考虑。比如Python社区中的Django、Pylons等等都是可以考虑的，那么在豆瓣的内部的话，我们一般是用web.py，很轻量的一 个Web框架来做，也是非常不错的选择，它可能需要自己做的事情多一点。但是，也不太可能完全重新设计了。

Q: 那如果要缓解高并发所带来的压力，Cache的利用肯定是一个非常有效的途径。那么豆瓣的缓 存命中率一般是多大？这方面的策略是怎样？

A: Memcache命中率一般都在97%左右，应该还算是比较高的。策略其实是比较简单的，如果每次要去执行一个比较耗时耗资源的操作，比如说去数据库查询 的话，就会以Python的Object形式存放在Memcache里面，下次再拿这个数据的时候就直接从Cache中拿就行了。这边选择什么样的东西， 尽量有一个Guideline，必须是要耗时的，耗资源的，而且是重复使用的。比如它是耗资源的，但是只用一次，Cache也没有意义。差不多用这种方法 保证Cache的东西都是真正有效的，也提高了命中率。

Q: 要提高承受高压力的流量，另外一个有效的措施是对数据库来进行分区分片，在这方面豆瓣是怎么 做的？

A: 豆瓣现在还没有达到数据库分片的程度。我们现在最常见的手段是，按照功能分区。我们会把数据表分成几个独立的库，现在是一共有4个库。每个表都是库的一个 部分，每个库会有主副两个。通过这种方式来减轻数据库的压力，当然这个是现在的方案，再往后的话，表的行数会增长，到达一定的程度后，还要进行水平分割， 这是肯定的。然后我们现在的技术方面，在操作数据库之前，首先获取数据库的游标，有一个方法，这个方法会干所有的事情，我们以后做的时候会从这个方法中进 行判断该从哪取东西。这个架构已经在了，只是现在还没有做这一步而已。

Q: 数据库这边主要采用什么解决方案呢？

A: 在数据库这边，我们主要用的是MySQL。MySQL有一个问题，大文本字段会影响它的性能。如果数据量过大的话，它会挤占索引的内存。那么现在一个行之 有效的方法是，我们另外建立一套可伸缩的Key-Value数据库，叫做DoubanDB。我们把不需要索引的大文本字段，放到DoubanDB里面去。 MySQL只保存需要索引的Relationship这方面的信息。这样给MySQL数据库降低了压力，也就可以保证它的性能。

Q: 比如说像保证数据的安全性，以及数据库的吞吐量，豆瓣是怎样的策略呢？

A: 首先DoubanDB会把每个数据在三个节点进行备份，任何一个出现故障都不会影响索取数据。MySQL是通过双Master方案，同时还会带1到2个 slave，所以说在MySQL中我们会有三到四个的备份。这点是可以放心的。

Q: 你刚才说到MySQL的双Master方案，这方面会不会存在什么问题？比如说同步的问题， 等等？

A: 在MySQL里面，双Master方案是一个比较经典的方案，我们现在用它很大一部分是为了解决我们同步延迟的问题。在做切换的时候，会出现同步延迟的问 题，但其实MySQL的同步速度还是可以的，在切换的时候，我们会忍受几秒钟等待同步的时间。在做脚本的切换的时候，我们会稍微等一下。

Q: 豆瓣的数据表一般是怎么样的规模？

A: 数据表，这个不好说了，因为不同的表都是不一样的。我们最大的表是“九点”的Entry表，“九点”的爬虫爬过来的所有的文章，现在应该有四千万左右的行 数。然后其他的上百万的表也有很多。还有包括收藏表也有千万级的行数。

Q: 在这种海量数据的情况下，对数据表的就结构变更，一定是一个比较麻烦的问题。常见的情况， 比如增加一个新的索引，会导致索引好几个小时。像豆瓣之前会存在这样的问题，是怎么解决的呢？

A: 这个问题曾经让我们吃过苦头，在忽视它的状况下就去改表，然后就锁了很长时间。后来我们意识到这个问题，如果有表的改动的话，我们会先在一个测试的库上试 验一下它的时间长短，是不是在可接受的范围，如果是可接受的范围，比如说几分钟，就做一个定时任务，在深夜里面去执行。如果耗时是不可忍受的，就必须通过 其他技术手段，我们现在的手段一般是建一个新表，这个新表从旧表同步数据，然后再写数据的时候，也会同步，往两边写，一直到两边完全一样了，再把旧表删 掉，大概是这样一个方式。

Q: 刚才您好像提过你们设计了自己的DoubanDB，还有一个是DoubanFS，这两者关 系是怎么样的？

A: 首先是先出来的DoubanFS，我们刚开始的时候用MogileFS来解决我们可扩展图片存储的问题，由于MogileFS有一个重型数据库，这成为了 它的性能瓶颈。我们为了解决这个问题，开发了DoubanFS，基于哈希来寻找节点。之后，我们又发现了新的问题，数据库中的大文本字段也会影响性能。所 以，我们在DoubanFS的基础上，换了一个底层，做了一些调整，参照Amazon的dynamo思想，搭建了DoubanDB，把文本字段放在 DoubanDB里面。做完之后，又反过来用DoubanDB来实现FS，大致是这么一个过程。

Q: DoubanFS跟DoubanDB的实现，他们在对于内容的安全性，或者内容的冗余性…

A: 都是（备份）三份。这都是可以配置的，现在的配置是3份。

Q: DoubanDB就是用什么机制实现的？

A: DoubanDB简单来说是这样子：你来一个Key，它是Key-Value数据库，你要写或读的时候，通过这个Key来寻找这个值。拿一个Key对它做 哈希，通过Consistent哈希方法去查找它在哪个节点上，然后往这个节点上去写或读。在这个节点上，顺着哈希的wheel顺次的找到第二、三个节 点，写的时候会保证这三个节点都写，读的时候是任意一个，如果其中一个读失败了，会自动切换到下一个。

Q: 您刚才提DoubanDB的话，是采用的技术是？

A: DoubanDB的底层存储用的是TokyoCabinet，是一个很轻量级、高效的Key-Value数据库。我们在它的基础之上，做了分布式，用这种 方式来实现的。

Q: 实际上有一些其他的方案可以解决，比如说像Berkeley DB（简称BDB）、CouchDB等等，你们为什么要选择TokyoCabinet？

A: 最简单的原因是由于它足够快，实际上BDB跟它比较类似，BDB更加强大一些。对我们而言，我们在这边就是需要一个可靠、高效的Key-Value存储， 这两个其实是我们都可以替换的，只要统一下接口就可以。CouchDB的话就是另外一个东西了，它是一个文档型数据库，它不仅仅做了一个Key- Value的工作，它还在这上面做了很多其他的事情，比如它有View的概念，可以进行query。这些TokyoCabinet是没有的，而我们暂时也 不需要这些功能。CouchDB是一个很有意思的数数据库，我们可能会在其他方面（应用），我们也在研究它。

Q: 从我们刚才的讨论中，Web前端你用了nginx又用了lighttpd。它们都是非常流 行的前端，这两种方案经常打架，豆瓣为什么把它们融合在一块？

A: 这是历史原因。我们其实没有刻意地去倾向某一个。这两个都是非常优秀的Web Server，都很轻量，都很高效。最开始的时候我们用的是lighttpd，然后是因为出现过一些问题，其实不是lighttpd的问题，但当时我们怀 疑可能是lighttpd有问题，就尝试了一下nginx，觉得这个也不错，然后这个结构就保留下来了。nginx对开发者和用户的友好性都更好一些。我 举个例子，比如说重启，其实在豆瓣的Web Server是经常要重启的，我们会有一个健康检查的脚本，定时的检查网站是不是正常，如果觉得不正常的话，就会做一些保护措施，其中就包括重启。 lighttpd的重启，是一个很粗暴的Kill。Nginx是一个reload的方案，会先把手头的事情做完了再重启。这样会好很多，而且它会在重启之 前会帮你做一些好的事情。所以，现在我们用Nginx越来越多。Nginx的配置文件也比lighttpd写起来更舒服一些。

Q: 豆瓣现在有一个庞大的用户群体，针对这样一些海量数据做好数据挖掘，肯定不是一件容易的事 情，能从技术这个角度讲讲挖掘的实现吗？

A: 在豆瓣专门有一个算法团队，他们的主要工作就是数据挖掘。这边讲技术实现的话，可能就讲不完了。只能讲一些大概，数据挖掘是怎么和前端结合起来的，让用户 看见的。每天用户在豆瓣上的操作都会产生很多数据，在豆瓣上面看到的东西，收藏的东西，都会存在数据库或是访问日志。每天这些信息都会传到算法团队的机器 上，然后会从这个数据中建立一个稀疏矩阵，你看过什么，干过什么。他们维维护了一个很高效的稀疏矩阵运算库，然后用它来做各种各样的尝试，去看是否能得到好 的结果，一旦发现这个结果很好，就会把它写到数据库里面。然后用户在访问的时候，前端从数据库中取出推荐给你的数据，然后把这些数据做一些过滤（比如你读 过的东西就不再给你展现了）、调整，最后展现给用户。基本上是这么一个逻辑。

From http://www.infoq.com/cn/interviews/douban-hqn;jsessionid=ED7EE84F6F31059E218CA06C5A4D33E6

临近两会，十三家媒体集体得瑟了一把；果然第二天文章就都被删得干干净净……这里做个存照。

　　中国患户籍制度之苦久矣！我们崇信人生而自由，人生而拥有自由迁徙之权利！然此诞生于计划经济时代、不合时宜地存在数十年之久之弊政至今仍时时困扰着 我广大民众，已到非革新不足以平息民怨，非革新不足以与时俱进之境地。为此，值全国两会召开之际，我们，全国11个省、自治区和直辖市的13家报纸发表共 同社论，提请两会代表与委员们，善用你们手中的权力，敦促有关部委提出户籍改革的明确时间表，逐步以人口信息登记制度取代现行僵化的户籍制度，直至最终将 其彻底消除！

　　中国《宪法》明文规定，中华人民共和国公民在法律面前一律平等，国家尊重和保障人权，公民的人身自由不受侵犯。迁徙自由 是人权和人身自由不可分割的组成部分，这是宪法赋予国民的基本权利。然而，现行的户籍政策却事实上造成了城市居民与农民、城市居民之间地位的不平等，制约 了中国公民的自由迁徙，明显与《宪法》相违背。我们都知道，一切法律、行政法规和地方性法规都不得同宪法相抵触，这是加速目前户籍制度改革的法理基础。

　 　户籍制度分割了城市和乡村。“农民工”是对那些户籍在农村而身在城市打工的人群的特定称谓，最早的一代农民工，为城市的发展付出了自己的劳动，可是，他 们的下一代仍然没有办法解决身份认同，他们的子女仍然背负着上一代的困惑，他们生活的城市仍然无法接纳他们，这才有了80后、90后农民工的称谓。我们要 问，这样的隔离究竟还要持续几代人？

　　即便在城市中，户籍制度也分割了城市的居民。在同一座城市中，尽管我们与其他人一样为这座城市的 建设奋斗多年，我们与其他人一样纳税，但没有户口让我们无法与其他人一样享受平等的就业机会，享受同等的医疗、教育、养老等等社会保障。因此，夫妻被迫两 地分居，年老的父母无法与子女团聚，孩子无法获得良好教育。我们要问，这样的隔离究竟还要持续几代人？

　　户籍制度还是滋生腐败的温床。 正因其稀缺，在很多城市户口成了被买卖的对象。有权者可以以此寻租，地产商可以以此为销售的工具，而千万的弱势群体要么付出金钱的代价，要么望洋兴叹地面 对种种不公的待遇。我们要问，这样的不平等究竟还要持续几代人？

　　温家宝总理不久前明确表示，中央已决定稳妥地推进户籍制度改革。而包 括上海、深圳、广州等全国数十个城市都已经出台户籍改革的措施。在这些城市，居住证正在逐步取代暂住证，持证者将可享受与当地居民相同的社保、医疗、教育 等公共服务。在一些城市中，农民工也正陆续被城市所接纳，他们迎来了迟到的尊严。同时，国家正在加快建立全国统一的社会保障社会化服务体系，实现社会保障 关系跨地区转移接续。建立个人终身社会保障号，并尽快实现全国联网，这为现行户籍制度改革的加速奠定了基础。

　　这些变化固然可喜，但在更多的地方，我们仍然失望地看到户籍这一无形而又沉重的枷锁，困住无数疲于奔命的人们。我们深知户籍政策之盘根错节，改革细节之错综复杂，然而我们更无法 漠视那些已经、正在以及仍将因此政策而受挫、受苦的人们。对于他们，等待改革的迫切让每一分钟的等待都显得非常漫长。

　　市场经济是由市 场配置资源的自由经济，人的流动是市场经济题中应有之义。我们在欣喜地看到中国经济飞速成长的同时，我们也要警醒经济结构的转型已经迫在眉睫。人口红利正 在消失，自然资源也非源源不绝，中国经济下一轮成长的动力已经更多地指向内部结构的调整与资源使用效率的优化，而非粗放式的外延扩张。户籍制度的改革不仅 利于民生，更能加速中国的城镇化进程，为中国经济注入更多的活力。更重要的是，户籍制度的改革将能帮助确立中国以人为本的价值理念，成为中国社会各阶层均 衡进步、构建和谐社会的基石。

　　为此，我们呼吁全国两会代表、委员，运用人民赋予你们手中的权力，敦促有关部委尽快废除1958年颁布 的《户口登记条例》，提出全国户籍制度改革的明确时间表，逐步以人口信息登记制度取代现行僵化的户籍制度，直至最终将其彻底消除。

　　我 们希望，我亿万国民，地无分南北，人不分城乡，都拥有同样的就业、医疗、养老、受教育、自由迁徙的权利。我们希望，一项为患数十年的弊政，能终止于我们这 一代人，让下一代人真正享有自由、民主、平等的宪法赋予的神圣权利！

目前Oracle有两个JVM，一个是JRockit， 这是两年前收购BEA Systems时得到的；另一个则是Sun的Hotspot VM，这是前不久收购Sun时得到的。在上个月举行的Sun-Oracle未来路线图会议上，Oracle的管理团队表示要合并这两个项目。Oracle 首席工程师、Sun前雇员Mark Reinhold最近在播客上透露该合并计划“仍在进行当 中”，为此也“召开了很多会议”。

Reinhold说到：

从长期的合并计划来看，目前很难对这二者作出取舍。现在我们还不会停止这两个JVM的开发工作，因为有很多客户的产品是运行在这 两个JVM之上并且使用了每个JVM独有的特性。我们可不想搞出什么震荡，那样只会把系统搞死，但还是衷心希望未来能有JVM一统天下。

Reinhold说这个计划至少还需要一年半到两年的时间才能成行。

这两个JVM各具优缺点，因此最好的方式还是取其精华，弃其糟粕。Reinhold说“在Oracle内，无论是工程团队还是管理团队都在尽最大努 力找出每个JVM的优点”。他接着说到：

坦率地说，我们这几年一直在嫉妒JRockit中的某些特性，其任务控制特性就非常棒。

而HotSpot的性能优势是比较明显的，他说到“我们对HotSpot代码基，尤其是server编译器的印象是其有很多的head room，这是一个更加复杂的系统”。

前几个月我们一直在学习JRockit，这真是一段令人难忘的时光。JRockit绝对是世界一流的VM，但其内部却是那么的不 同。JRockit和HotSpot各具优势，因此我们将要创建一个非常帅的项目——综合JRockit和HotSpot各自的优势。

Reinhold推测合并后的VM将使用JRockit的垃圾回收器与服务功能，使用HotSpot的运行时编译器与混合的运行时系统。

在播客中，Reinhold还提到了JDK7的模块化特性（模块化可以让Java更有效地进入到小型设备领域）、通过invokeDynamic实 现的多语言能力以及通过ProjectCoin提升Java语言本身的生产力。开发者应该玩玩Jigsaw，而openJDK Build 88则将于下月中旬发布。

查看英文原文：Mark Reinhold Talks About JRockit/Hotspot Integration

豆瓣的九点是一个比较独特的RSS聚合站点，和一般的RSS阅读器及抓虾鲜果之类的聚合不同，有一种想做媒体门户的意思。

但 是九点这个东西，确实是太白痴了，RSS抓取的间隔无限长，文章更新一周后还未更新的现象比比皆是，九点的豆瓣小组里充满了询问RSS更新的帖子。豆瓣一直自诩技术狂热的公司，做出这么一个产品来真是丢人丢大发了。

我在在九点订阅了我自己blog的RSS，刚开始的时候情况还好， 顶多延迟一两天就会更新，最近一段时间干脆就不更新了。豆瓣还提供了一个手动点击更新RSS的链接，点了以后就会提示说已经抓取，10分钟以后再来看结 果。实际上这个链接半点用处都没有，我都点了一天了也没见更新。

于是我就跑到豆瓣的九点小组里发文，题目叫《真的，我建议九点改名叫13点》，抱怨九点抓 取的无比缓慢和难以捉摸。没想到刚发完文不到一个小时订阅的RSS就更新了！之前也有人说只要发豆邮给管理员，就会帮助手工更新，看样子确实不假。

回家过年，结果就在春节那天感冒了。这一感冒，就病得跌宕起伏，连绵不绝……

在家里吃了两天药，回到北京的时候感觉基本上好了，就老老实实的到公司上班去了；未想上班第二天，喉咙又开始痛了，且四肢发酸。去附近亚运村医院就诊，结果是低烧加扁桃体发炎。医生很大方的开了四西药两中药，总共200多块钱，外加挂号费两块五毛、血常规化验费20。

不得不说医生很有水平，开了这么多药，没有一种是我认识的，并且价格又贵，又没效果。其实开药的时候我就明白了，这就是把治疗感冒、咳嗽、炎症的药，不管有用没用都开出来，反正这么多样总有一样会能治病的。

悲剧的是这六样药好像是真的没有能治病的，尤其是其中的中药，很难喝，还引起腹泻。过了两天，扁桃体发炎非常的恶化了，吞咽不能，而且不停的咳嗽。鉴于对亚运村医院的不信任，这次就跑到中关村医院，告诉大夫说我那药吃了几天了，病不见好，发炎还更厉害了。大夫心虚的瞅了我一眼，说“那输液吧”。于是开了两天的输液，药费168大洋，外加挂号费两块五，血常规20，输液费32……

输液的护士MM说：你的血管好细！拿着针头在我右手上来回扎了三四下，说终于好了。没等她这口气出完，手背就肿了，护士说，我们换左手扎吧……

输液果然有点作用，两天后虽然咳嗽还很厉害，但是好歹扁桃体炎症终于消了。

年27坐火车回家，坐的是一个绿皮车硬座，代号1461，车票异常的便宜，只要53块钱。火车上人很多，几乎全都是在北京打工的山东人。这些个山东人非常的能吹，具体怎么能吹我就不描述了，怕伤害淳朴的山东人民的感情，山东人彪起来不好对付。

后来车过了泰安，山东人几乎下光了，座位空了出来。一个小姑娘坐到我旁边了，对面换了一个带着小孩的蚌埠夫妻。

和大多外出打工的年轻女孩一样，小姑娘扎了个马尾辫子，签名挺长的刘海，脸脸两旁垂下两缕头发来，脸蛋红扑扑的。她坐过来以后就找我搭话，就这样谈了起来。小姑娘原来是河南信阳的，看起来挺小，来北京打工已经两年了，换了三个工作，这次是要到苏南找他表妹玩去。

时间过得特别快，徐州站很快到了，我搬下箱子准备下车。对面的蚌埠老公悄悄跟我说:

"你不找她要手机号吗?太可惜了"

“啊？”

"下了车好联系啊，我看你们挺有夫妻相的"

我有点无语。是的，女孩挺不错，但是我也明白，我现在已经不可能是找个在理发店或者服装厂打工的女孩子做老婆的人了。而且，我也太老了，无法面对眼睛忽闪，充满青春、希望和憧憬的小孩子。

上次被别人说有夫妻相还是两年前和我表姐从武汉回来的时候。现在她都已经嫁人了，婚礼就在27号，我上火车的前一天，我没能赶上。

最终列车晚点了一个小时，凌晨一点钟到站。徐州下起了鹅毛大雪，看样子第二天公交、短途客运也都没的走了。无奈下花了150￥打车回家——这很让我爸我妈耿耿于怀，喋喋不休一直唠叨到我坐上回程的火车。

第二天路上车果然奇少，行使的很慢，散步似的。即使这样也还是会出事，当天上午眼睁睁看见公路上一辆面包车冲出路面，斜着停在了路基的斜坡上，里面的人慌忙打开车门都跑了出来。这是整个春节假期期间最让我兴奋的一件事。

昨天早上起的太早，迷迷糊糊的，到ATM里取了300块钱，拿到了钱就转头走了。过了俩小时翻钱包发现卡没了，想起来是忘在ATM里了。急忙赶回银行，正好取款机那里迎面碰到一女桂圆，连忙给她比划着说我今天早上取了钱，卡拉在取款机了，你看就中间那台。桂圆看了下取款机，一切正常，说我们这里也没有收到卡啊，你赶紧挂失吧，我们那有电话，我带你过去……心里慌啊，要是我一直没取卡，ATM该把卡吞了吧，现在没吞也没人上交，那是不是有人拿了卡取钱走了。

赶忙挂失、换卡，出来一查，所幸分文未少。工行桂圆看到我是代发工资的卡，推荐我办他们家信用卡，我前端时间申请国航知音被据了，心想就不再自取其辱了。整个过程损失挂失+换卡费用大洋25元整。

自从来到北京后，三次把卡丢到ATM里，一次把信用卡不知道丢到哪里，一次把信用卡当作借记卡查到ATM里取现，真是损失惨重。

《孔子》那群家伙一直以为《阿凡达》是它票房的最大敌人，胡玫整天揭批《阿凡达》，还说相信中国人会做出正确的选择。现在看来中国人的正确选择已经做出来了，非常非常低调的《喜羊羊与灰太狼2》已经完胜宣传炒作铺天盖地无所不至的《孔子》，票房过亿不成问题。果真如此，从拍片以来就无比高调高调的胡玫和发哥情何以堪！

广电总局勒令《阿凡达》2D下线又有什么用呢！反正场次不会给你孔子的。

另外永远的正太——柯南剧场版《漆黑的追迹者》上映后票房无比惨淡。这是柯南剧场版首次在大陆上映，看样子也多半是最后一次。不得不说，柯南最近的剧场版真的是一代烂过一代，已经完全没有人气了。