我上网搜索了别人这方面的问题，还真不少（不小的老外为啥也要写这么长的post……），基本上是建议直接修改php.ini增加内存限制或修改httpd.conf或者直接在.htaccess中增加一句话：

php_value memory_limit 64M

这句话的目的在于直接改变php的内存占用上限为64M，我兴冲冲地修改了，然后垂头丧气地得到了一个500 server error错误……看来我的服务商并没给我这么高的权限，让我做这种可能危害到全服务器的行为。迫不得已，我直接修改了wordpress的两个源文件：/wp-admin/post-new.php和/wp-admin/post.php。在这两个文件的第一个require之后增加一句话：

ini_set('memory_limit','64m');

这起的作用是一样的，也是改变php内存上限为64M，不过这个上限只存在于这个页面的生存期内，也就是不像httpd.conf和.htaccess那样影响到全局，相对来说对服务器的影响也稍微小一些，经测试也确实可行，至少目前我发33万字的内容没太大问题（自动保存草稿还是会出错，不过那个无伤大雅），只是担心wordpress对超长文本的分页是如何进行的，害怕会出现占用内存过大的情况，我试试监控服务器的内存使用，我一般也就占用8%左右，偶尔飚到10%，先这么做吧，看看服务器的负载是否能够承受，顺便再启用几个wordpress缓存插件，降低一些对内存的需求。

今天下午在小毅的提醒下，我试着将js禁用，发现链接颜色恢复正常！

难道是我的脚本里设置了超链接颜色？？貌似我不会自己做这种事情，那会是谁做的？

我突然注意到一点，颜色出错的超链接都是没单独定义颜色的，它们都是继承自全局的超链接颜色设置，那会不会是我哪里的程序修改了全局的样式呢？

我再次检查我的脚本，我看了一下我的脚本文件，最终注意力集中在实现自定义tooltip的脚本文件上，所有的脚本，只有这个是我从网上取得，稍加修改使用的，难道是它？

我打开tooltip.js，巡视了代码，但并没看见什么设置样式表的函数，除了一个：

function AddCss(){
  var l=CreateEl("link");
  l.setAttribute("type","text/css");
  l.setAttribute("rel","stylesheet");
  l.setAttribute("href","bt.css");
  l.setAttribute("media","screen");
  document.getElementsByTagName("head")[0].appendChild(l);
}

这个函数的作用是将tooltip对应的样式表动态加载进来，由于我后来修改了路径及文件名，这段脚本实际上已经不起作用。我顺手将它注释。奇迹发生了……我发现在opera下超链接颜色正常了……

我开始检查opera的error console(下图)，发现里面关于这个css的错误很多，居然有中文？我直接访问这个css的地址，文件不存在，出来的当然是一个404的页面。

404…404的超链接就是红色的…我查看了一下源代码:

  BODY { font: 9pt/12pt 宋体 }
  H1 { font: 12pt/15pt 宋体 }
  H2 { font: 9pt/12pt 宋体 }
  A:link { color: red }
  A:visited { color: maroon }

color: red，我苦苦寻找不得的这句话居然出现在一个404页面里……

至此，问题解决。由于自己的小疏忽或者叫做懒惰，没去除无效代码，而导致在一个特定的浏览器下出现奇怪的显示错误。不过话说回来，opera对文件的解析能力也真强……ie、ff在读到404错误之后就停止获取文件内容，而opera不仅继续解析，还把404页面中的样式表读了进来，搞了这么一个“有趣”的bug……无语

在最后再次感谢小毅和怿飞，他们在这次解决问题中给了不小的帮助，谢谢。