script标签有两种用途：
1. 在页面中标识一块脚本代码
2. 加载一个脚本文件
它要依赖于src属性的存在。上面两种情况都需要</script>闭合标签。
如果存在src属性，它的值应是一个url(网址)表示的.js文件。当浏览器加载，编译与执行文件时，页面将停止装载与处理。<script src="url">与</script>之间不应有任何内容(保持空白)。
如果没有src属性，<script>与</script>之间的文字可被编译与执行。
你可以直接在前台页面里的<script type="text/javascript">这个标签之间写js代码</script>
也可以在一个js文件里面写，然后用src属性引用进来比如<script src="JavaScript/myjs.js" type="text/javascript"></script>
<script src="url"></script>将阻碍页面的其它组件下载，直到script脚本加载、编译、执行完毕。因此越晚调用脚本越好，以便加载图像和其它组件不被延时。
因此通常最好把所有的<script src="url"></script>放置在</body>之前。一个页面内的<script>在加载时没有明显的影响。
script标签应该放在哪儿:
一般script标签会被放在头部或尾部。头部就是<head>里面，尾部一般指<body>里。 将script放在<head>里，浏览器解析HTML，发现script标签时，会先下载完所有这些script，再往下解析其他的HTML。
讨厌的是浏览器在下载JS时，是不能多个JS并发一起下载的。不管JS是不来来自同一个host，浏览器最多只能同时下载两个JS，且浏览器下载JS时，就block掉解析其他HTML的工作。
将script放在头部，会让网页内容呈现滞后，导致用户感觉到卡。所以yahoo建议将script放在尾部，这样能加速网页加载。 将script放在尾部的缺点，是浏览器只能先解析完整个HTML页面，再下载JS。而对于一些高度依赖于JS的网页，就会显得慢了。所以将script放在尾部也不是最优解，最优解是一边解析页面，一边下载JS。 所以提出了一种更modern的方式：使用async和defer。80%的现代浏览器都认识async和defer属性，这两个属性能让浏览器做到一边下载JS(还是只能同时下载两个JS)，一边解析HTML。
他的优点不是增加JS的并发下载数量，而是做到下载时不block解析HTML。带async属性的script会异步执行，只要下载完就执行，这会导致script2.js可能先于script1.js执行（如果script2.js比较大，下载慢）。
defer就能保证script有序执行，script1.js先执行，script2.js后执行。
<script type="text/javascript" src="path/to/script1.js" async></script> <script type="text/javascript" src="path/to/script2.js" async></script>
结论
1. 如果可以不考虑支持IE9，最好的做法是将script标签放在head中，并使用async/defer属性。这样浏览器就能一边下载JS，一边解析其他的HTML。
2. Google自己的代码script放的也有点乱，有的放在</body>后面，有的放在<body>里面，还有的放在<head>里面。总体来说，放在<body>里其实是最常见的做法。
3. 本文只讨论script的位置，至于link和style，还是放在head里的做法比较常见。link也是要下载CSS的啊，为毛不考虑下载CSS阻塞HTML解析的问题呢？其实，一般情况下，JS和CSS，放在head和放在body区别不大。CSS的link放在body也是可以的，只是可能导致页面暂时没有样式。
转自：http://blog.csdn.net/ybdesire/article/details/49284699
来源：知乎
Google并没有把<script>插入在</body>之后，而只是没有写</body>和</html>闭合标签。 【这样做是符合标准的。不仅是html5标准，从第一个HTML正式标准HTML 2.0开始，这样做都是允许的。相反，在</body>之后插入其他元素，从HTML 2.0起就是不合标准的。】
新浪微博确实有在</body>之后输出<script>。
新浪微博所用的doctype是XHTML 1.0，但是其response的content type头并没有用XHTML mimetype，所以浏览器仍然会按HTML语法进行parsing。【顺便说一句，虽然新浪微博用了XHTML 1.0 DTD，但是其实际内容连well-formed也没有做到，是典型的挂羊头卖狗肉的XHTML。新浪的前端同学们应该检讨一下啊！当然了，腾讯微博也是用XHTML 1.0的DTD，并且也不是well-formed的，跟新浪微博是难兄难弟啊！如果说一定要较个高下，那企鹅还是略胜一筹——其网页出现第一个解析错误的行数更靠后一点。】
按照HTML5标准中的HTML语法规则，如果在</body>后再出现<script>或任何元素的开始标签，都是parse error，浏览器会忽略之前的</body>，即视作仍旧在body内。所以实际效果和写在</body>之前是没有区别的。
总之，这种写法虽然也能work，但是并没有带来任何额外好处，实际上出现这样的写法很可能是误解了“将script放在页面最末端”的教条。所以还是不要这样写为好。
【补充】
有同志说因为新浪微博使用bigpipe，所以“从直觉触发，为了避免浏览器出现未知异常，应该在首次吐出的页面框架中闭合body”。但是这个逻辑上说不通。因为在body以外写script也可能存在其他异常嘛。有什么理由能让开发者推断出后者会更安全呢？实际上在没有充分测试的前提下，如果要进行推断，那么可以推断出后者的风险更大。
第一，这是不合标准的行为，而且从有HTML标准以来都是不合标准的，因此浏览器实现不一致或者在这种情况下有bug的风险显然更大。
第二，虽然将<script>写在</body>之后，但最终的DOM树里，<script>元素还是会成为body的子节点，这一点很容易在firebug等调试器里验证。既然如此，如果将<script>写在</body>之前会有问题，你又如何保证写在之后（并在DOM里又变成了和写在之前一样的结构）就没有问题？基于规则 %html.content "HEAD|BODY" HTML 标签的子元素只能是 HEAD BODY。
但是浏览器对HTML(XHTML)均有容错机制。 错误嵌套的标签、以及位置放置错误的标签都会在paser HTML 过程中尝试修复。修复后得到合法的HTML后在由布局引擎建立相应的DOM对象。
在<script>标签放置于</body>标签之后时，源码被所有浏览器【泛指PC上常见的】修复为正常形式，即<script></script></body>。
由此，Google 这种利用基于浏览器修复【或规范中可以不闭合标签条款的】机制，处理是可以的。它的意图是尽可能少输出内容，由客户端浏览器来辅助它处理HTML，最终目的是为了提速与尽可能加大服务端吞吐量。
至于新浪微博的问题，比较复杂，只能推测下。
新浪微博默认采用【非IE6下】bigpipe机制分块输出页面内容。这需要在首块时候就吐出页面框架结构给浏览器。那么这个先吐出的页面结构是否需要闭合</body>标签呢？
从直觉触发，为了避免浏览器出现未知异常，应该在首次吐出的页面框架中闭合body。那么，之后分块输出的 script 标签必然会被打印在 </body>之后，然后依赖浏览器修复机制执行代码。
新浪微博当时的工程师们可能并不知道修复机制，仅仅是为了避免项目风险，经过测试后发现这么做可行，就这么做了。
不管怎样，基于bigpipe机制分块吐出机制，在body没有闭合，页面数据继续到达的情况下，之后被吐出的script代码很可能存在操作document.body对象，这样可能会导致异常，你我做如此实现时候都必须掂量下是否要冒风险不闭合body标签。
此外，对于贺老祖的一些解释，偶表示部分不认同。
content type 的问题。
rfc3236 规定了 application/xhtml+xml 这样的 XHTML mimetype 来表示一个XHTML文件。但是浏览器并不一定按照这个 mimetype 来解析，偶从开源浏览器代码中【Gecko/Webkit】只看到 parser HTML 部分的实现，这部分内容对于 XHTML 是无特殊处理的，就是说即使是 XHTML 也会被当做 HTML parser。唯一有一点不同的是，页面的 DTD 如何写会被浏览器嗅探，用来触发三种不同的文档模式【怪异、近乎标准、标准】。至于当前文档的 mimetype 是什么，对解析 HTML 或者渲染的影响，没有得到很明显的源码证据。
【当然，基于network层是会区分mimetype 的，它会筛选出它认为是HTML的类型交付HTML parse 处理。事实上IE会比其他浏览器做的要更多，对于非二进制类型，会启用“HTML嗅探机制”，如果首200字符内有特定HTML标记，则会将文档交由HTML parse 处理】。
贺老祖【】内表述的挂羊头卖狗肉行为偶就不细说了，仅当做 贺老祖 个人情绪发泄。个人感觉没必要太学院了，实际适用就好。
总结：两种方式实际使用上没有什么区别，唯一差异在于你是否要利用浏览器的自动修复机制。当然，理论上讲，利用了自动修复机制必然会导致性能有损失。