Javascript 不允许您向对象提供私有数据或方法，就像在 C++ 中那样。哦，实际上，是的，通过一些涉及关闭的解决方法。但是来自 Python 背景，我倾向于相信“假装隐私”（通过命名约定和文档）已经足够好，甚至可能比“强制隐私”（由 Javascript 本身强制执行）更可取。当然，我可以想到不正确的情况——例如，人们在没有 RTFM 的情况下与我的代码交互，但我受到了指责——但我不是那种情况。
但是，有些事情让我停下来。Javascript 大师 Douglas Crockford 在“Javascript: The Good Parts”和其他地方一再将虚假隐私称为“安全”问题。例如，“攻击者可以轻松地直接访问字段并用自己的方法替换方法”。
我对此感到困惑。在我看来，如果我遵循最低限度的安全做法（验证，不要盲目信任从浏览器发送到我的服务器的数据；不要在我的网站上包含第三方脚本而不检查它们），那么就没有假装隐私不如强制隐私“安全”。是对的吗？如果不是，假装隐私与强制隐私具有安全含义的情况是什么？
不是本身。然而，正如 Crockford 指出的那样，这确实意味着您不能安全地将不受信任的 JavaScript 代码加载到 HTML 文档中。如果您确实需要在浏览器中运行此类不受信任的 JavaScript 代码（例如，用于社交网站中用户提交的小部件），请考虑 iframe 沙盒。
作为 Web 开发人员，您的安全问题通常是主要的 Internet 广告代理不支持（甚至禁止）构建他们的广告代码。不幸的是，您必须相信 Google 不会提供恶意 JavaScript，无论是有意还是无意（例如，它们被黑客入侵）。
这是我作为另一个问题的答案发布的 iframe 沙盒的简短描述：
为用户提交的 HTML、CSS 和 JavaScript设置一个完全独立的域名（例如“exampleusercontent.com”） 。不允许通过您的主域名加载此内容。然后使用 iframe 将用户内容嵌入到您的页面中。
如果您需要比简单框架更紧密的集成，
window.postMessage()可能会有所帮助，允许不同框架中的脚本以受控方式相互通信。
答案似乎是“不，假隐私很好”。以下是一些详细说明：
在当今存在的 javascript 中，您不能在网页上包含未知且不受信任的第三方脚本。它可以造成严重破坏：它可以重写页面上的所有 HTML，它可以提示用户输入他的密码，然后将其发送到一个邪恶的服务器等等。Javascript 编码风格对这个基本事实没有任何影响。有关处理此问题的方法的讨论，请参阅PleaseStand 的回答。
一个不称职但不邪恶的脚本可能会无意中通过名称冲突把事情搞砸。这是反对创建大量具有通用名称的全局变量的一个很好的论据，但与是否避免假私有变量无关。例如，我的香蕉销售网站可能使用 fake-private 变量window.BANANA_STORE_MODULE.cart.__cart_item_array。第三方脚本意外覆盖此变量并非完全不可能，但极不可能。
有一些想法是为了将来修改javascript 提供一个受控环境，在该环境中不受信任的代码可以以规定的方式运行。我可以让不受信任的第三方 javascript 通过特定的公开方法与我的 javascript 交互，并阻止第三方脚本访问 HTML 等。如果这种情况存在，则可能是私有变量对于安全性至关重要的场景。但它还不存在。
显然，编写清晰且无错误的代码总是有助于安全性。只要真正私有的变量和方法使编写清晰且无错误的代码变得更容易或更难，就存在安全隐患。它们是否有用总是一个争论和品味的问题，以及你的背景是，比如说，C++（私有变量是核心）还是 Python（私有变量不存在）。两个方向都有争论，包括著名的博客文章Javascript Private Variables are Evil。
就我而言，我将继续使用虚假隐私：前导下划线（或其他任何内容）向我和我的合作者表明某些属性或方法不是模块的公共支持接口的一部分。我的假隐私代码更具可读性（IMO），并且我在构建它时有更多自由（例如，闭包不能跨越两个文件），并且我可以在调试和实验时访问那些假私有变量。我不会担心这些程序比任何其他 javascript 程序更不安全。