任何window可以在任何其他的window上使用这个方法，在任何的时候，不管当前页面在window中的location，来发送信息。
所以，任何的对象监听被使用来接受信息时必须先检查信息发送着的身份，使用origin和可能使用的属性source来判断。
这个必须再三声明：不检查origin和source可能会导致跨站点脚本攻击。
和任何的异步执行的脚本（timeout,用户生成的脚本），调用postMessage来监听何时事件处理函数监听postMessage发送的事件对象是不可能的，将会抛出错误。
发送对象的origin属性是不会受到当前在调用窗口的document.domain值的影响。
For IDN host names only, the value of the origin property is not consistently Unicode or punycode; for greatest compatibility check for both the IDN and punycode values when using this property if you expect messages from IDN sites. This value will eventually be consistently IDN, but for now you should handle both IDN and punycode forms.
The value of the origin property when the sending window contains a javascript: or data:URL is the origin of the script that loaded the URL.
Using window.postMessage in extensions
window.postMessage is available to JavaScript running in chrome code (e.g., in extensions and privileged code), but the source property of the dispatched event is always null as a security restriction. (The other properties have their expected values.) The targetOrigin argument for a message sent to a window located at a chrome: URL is currently misinterpreted such that the only value which will result in a message being sent is "*". Since this value is unsafe when the target window can be navigated elsewhere by a malicious site, it is recommended thatpostMessage not be used to communicate with chrome: pages for now; use a different method (such as a query string when the window is opened) to communicate with chrome windows. Lastly, posting a message to a page at a file: URL currently requires that the targetOriginargument be "*". file:// cannot be used as a security restriction; this restriction may be modified in the future.
Browser compatibility
[1] Prior to Gecko 6.0 (Firefox 6.0 / Thunderbird 6.0 / SeaMonkey 2.3), the message parameter must be a string. Starting in Gecko 6.0 (Firefox 6.0 / Thunderbird 6.0 / SeaMonkey 2.3), themessage parameter is serialized using the structured clone algorithm. This means you can pass a broad variety of data objects safely to the destination window without having to serialize them yourself.
[2] Gecko 8.0 introduced support for sending File and FileList objects between windows. This is only allowed if the recipient's principal is contained within the sender's principal for security reasons.
[3] IE8 and IE9 only support it for <frame> and <iframe>.
[4] IE10 has important limitations: see this article for details.