假如纯粹是为了挑战本身的正则程度，用来实现一些特效（譬喻利用正则表达式计较质数、解线性方程），效率不是问题；假如所写的正则表达式只是为了满意一两次、几十次的运行，优化与否区别也不太大。可是，假如所写的正则表达式会百万次、千万次地运行，效率就是很大的问题了。我这里总结了几条晋升正则表达式运行效率的履历（事情中学到的，看书学来的，本身的体会），贴在这里。假如您有其它的履历而这里没有提及，接待见教。
为行文利便，先界说两个观念。
误匹配：指正则表达式所匹配的内容范畴超出了所需要范畴，有些文本显着不切合要求，可是被所写的正则式“击中了”。譬喻，假如利用\d{11}来匹配11位的手机号，\d{11}不光能匹配正确的手机号，它还会匹配98765432100这样的明明不是手机号的字符串。我们把这样的匹配称之为误匹配。
漏匹配：指正则表达式所匹配的内容所划定的范畴太狭窄，有些文本确实是所需要的，可是所写的正则没有将这种环境席卷在内。譬喻，利用\d{18}来匹配18位的身份证号码，就会遗漏末了是字母X的环境。
写出一条正则表达式，既大概只呈现误匹配（条件写得极宽松，其范畴大于方针文本），也大概只呈现漏匹配（只描写了方针文本中多种环境种的一种），还大概既有误匹配又有漏匹配。譬喻，利用\w+\.com来匹配.com末了的域名，既会误匹配abc_.com这样的字串（正当的域名中不含下划线，\w包括了下划线这种环境），又会遗漏ab-c.com这样的域名（正当域名中可以含中划线，可是\w不匹配中划线）。
精准的正则表达式意味着既无误匹配且无漏匹配。虽然，现实中存在这样的环境：只能看到有限数量的文本，按照这些文本写法则，可是这些法则将会用到海量的文本中。这种环境下，尽大概地（假如不是完全地）消除误匹配以及漏匹配，并晋升运行效率，就是我们的方针。本文所提出的履历，主要是针对这种环境。
把握语法细节。正则表达式在各类语言中，其语法大抵沟通，细节半斤八两。明晰所利用语言的正则的语法的细节，是写出正确、高效正则表达式的基本。譬喻，perl中与\w等效的匹配范畴是[a-zA-Z0-9_]；perl正则式不支持必定逆序环顾中利用可变的反复（variable repetition inside lookbehind，譬喻(?<=.*)abc），可是.Net语法是支持这一特性的；又如，JavaScript连逆序环顾（Lookbehind,如(?<=ab)c）都不支持，而perl和python是支持的。《能干正则表达式》第3章《正则表达式的特性和门户概览》明晰地列出了各大派系正则的异同，这篇文章也简腹地列出了几种常用语言、东西中正则的较量。对付详细利用者而言，至少应该具体相识正在利用的那种事情语言里正则的语法细节。
先粗后精，先加后减。利用正则表达式语法对付方针文本举办描写和界定，可以像画素描一样，先大抵勾勒出框架，再慢慢在局步实现细节。仍举适才的手机号的例子，先界定\d{11}，总不会错；再细化为1[358]\d{9}，就向前迈了一大步（至于第二位是不是3、5、8，这里无意深究，只举这样一个例子，说明慢慢细化的进程）。这样做的目标是先消除漏匹配（刚开始先尽大概多地匹配，做加法），然后再一点一点地消除误匹配（做减法）。这样有先有后，在思量时才不易堕落，从而向“不误不漏”这个方针迈进。
留有余地。所能看到的文本sample是有限的，而待匹配检讨的文本是海量的，临时不行见的。对付这样的环境，在写正则表达式时要跳出所能见到的文本的圈子，开辟思路，作出“计谋性前瞻”。譬喻，常常收到这样的垃圾短信：“发*票”、“发#漂”。假如要写法则屏蔽这样烦人的垃圾短信，不单要能写出可以匹配当前文本的正则表达式 发[*#](?:票|漂)，还要可以或许想到 发.(?:票|漂|飘)之类大概呈现的“变种”。这在详细的规模或者会有针对性的法则，不多言。这样做的目标是消除漏匹配，耽误正则表达式的生命周期。
明晰。详细说来，就是审慎用点号这样的元字符，尽大概不消星号和加号这样的任意量词。只要能确定范畴的，譬喻\w，就不要用点号；只要可以或许预测反复次数的，就不要用任意量词。譬喻，写析取twitter动静的剧本，假设一条动静的xml正文部门布局是<span class=”msg”>…</span>且正文中无尖括号，那么<span class=”msg”>[^<]{1,480}</span>这种写法的思路要好于<span class=”msg”>.*</span>，原因有二：一是利用[^<]，它担保了文本的范畴不会超出下一个小于号地址的位置；二是明晰长度范畴，{1,480}，其依据是一条twitter动静大抵能的字符长度范畴。虽然，480这个长度是否正确还可推敲，可是这种思路是值得警惕的。说得狠一点，“滥用点号、星号和加号是不环保、不认真任的做法”。