我更喜欢将私有数据存储在关联的WeakMap中。这允许你将你的公共方法保留在原型上。对于大量的对象，这似乎是处理这个问题的最有效的方法。

const data = new WeakMap();

function Foo(value) {
    data.set(this, {value});
}

// public method accessing private value
Foo.prototype.accessValue = function() {
    return data.get(this).value;
}

// private 'method' accessing private value
function accessValue(foo) {
    return data.get(foo).value;
}

export {Foo};

我更喜欢将私有数据存储在关联的WeakMap中。这允许你将你的公共方法保留在原型上。对于大量的对象，这似乎是处理这个问题的最有效的方法。

const data = new WeakMap();

function Foo(value) {
    data.set(this, {value});
}

// public method accessing private value
Foo.prototype.accessValue = function() {
    return data.get(this).value;
}

// private 'method' accessing private value
function accessValue(foo) {
    return data.get(foo).value;
}

export {Foo};

别啰嗦了。这是Javascript。使用命名约定。

在es6类工作了多年之后，我最近开始了一个es5项目(使用requireJS，它看起来已经非常冗长了)。我已经反复研究了这里提到的所有策略，基本上都可以归结为使用命名约定:

Javascript doesn't have scope keywords like private. Other developers entering Javascript will know this upfront. Therefore, a simple naming convention is more than sufficient. A simple naming convention of prefixing with an underscore solves the problem of both private properties and private methods. Let's take advantage of the Prototype for speed reasons, but lets not get anymore verbose than that. Let's try to keep the es5 "class" looking as closely to what we might expect in other backend languages (and treat every file as a class, even if we don't need to return an instance). Let's demonstrate with a more realistic module situation (we'll use old es5 and old requireJs).

my-tooltip.js

    define([
        'tooltip'
    ],
    function(
        tooltip
    ){

        function MyTooltip() {
            // Later, if needed, we can remove the underscore on some
            // of these (make public) and allow clients of our class
            // to set them.
            this._selector = "#my-tooltip"
            this._template = 'Hello from inside my tooltip!';
            this._initTooltip();
        }

        MyTooltip.prototype = {
            constructor: MyTooltip,

            _initTooltip: function () {
                new tooltip.tooltip(this._selector, {
                    content: this._template,
                    closeOnClick: true,
                    closeButton: true
                });
            }
        }

        return {
            init: function init() {
               new MyTooltip();  // <-- Our constructor adds our tooltip to the DOM so not much we need to do after instantiation.
            }

            // You could instead return a new instantiation, 
            // if later you do more with this class.
            /* 
            create: function create() {
               return new MyTooltip();
            }
            */
        }
    });

以遵循Crockford私有或特权模式的任何解决方案为例。例如:

function Foo(x) {
    var y = 5;
    var bar = function() {
        return y * x;
    };

    this.public = function(z) {
        return bar() + x * z;
    };
}

在任何情况下，如果攻击者在JS上下文中没有“执行”权，他就没有办法访问任何“公共”或“私有”字段或方法。如果攻击者有访问权限，他可以执行以下一行代码:

eval("Foo = " + Foo.toString().replace(
    /{/, "{ this.eval = function(code) { return eval(code); }; "
));

注意，上面的代码对于所有构造函数类型-privacy都是通用的。这里的一些解决方案会失败，但应该清楚的是，几乎所有基于闭包的解决方案都可以通过不同的replace()参数像这样被破坏。

在此执行之后，任何用new Foo()创建的对象都将有一个eval方法，可以调用该方法来返回或更改构造函数闭包中定义的值或方法，例如:

f = new Foo(99);
f.eval("x");
f.eval("y");
f.eval("x = 8");

我能看到的唯一问题是，它不会工作的情况下，只有一个实例，它是在加载时创建的。但这样就没有理由真正定义原型了，在这种情况下，攻击者可以简单地重新创建对象，而不是构造函数，只要他有方法传递相同的参数(例如，它们是常量或从可用值计算出来的)。

在我看来，这使得Crockford的解决方案毫无用处。由于“隐私”很容易被打破，他的解决方案的缺点(可读性和可维护性降低，性能下降，内存增加)使得基于“无隐私”原型的方法成为更好的选择。

我通常使用前导下划线标记__private和_protected方法和字段(Perl风格)，但在JavaScript中拥有隐私的想法只是表明它是一种被误解的语言。

因此，除了Crockford的第一句话外，我不同意他的观点。

那么如何在JS中获得真正的隐私呢?将所有需要私有的东西放在服务器端，并使用JS进行AJAX调用。

var TestClass = function( ) {

    var privateProperty = 42;

    function privateMethod( ) {
        alert( "privateMethod, " + privateProperty );
    }

    this.public = {
        constructor: TestClass,

        publicProperty: 88,
        publicMethod: function( ) {
            alert( "publicMethod" );
            privateMethod( );
        }
    };
};
TestClass.prototype = new TestClass( ).public;


var myTestClass = new TestClass( );

alert( myTestClass.publicProperty );
myTestClass.publicMethod( );

alert( myTestClass.privateMethod || "no privateMethod" );

类似于georgebrock，但不太啰嗦(恕我直言) 这样做有什么问题吗?(我哪儿都没见过)

编辑:我意识到这有点没用，因为每个独立的实例化都有自己的公共方法副本，从而破坏了原型的使用。

在这些情况下，当你有一个公共API，并且你想要私有和公共的方法/属性时，我总是使用模块模式。这个模式在YUI库中很流行，详细信息可以在这里找到:

http://yuiblog.com/blog/2007/06/12/module-pattern/

它非常简单明了，其他开发人员也很容易理解。举个简单的例子:

var MYLIB = function() {  
    var aPrivateProperty = true;
    var aPrivateMethod = function() {
        // some code here...
    };
    return {
        aPublicMethod : function() {
            aPrivateMethod(); // okay
            // some code here...
        },
        aPublicProperty : true
    };  
}();

MYLIB.aPrivateMethod() // not okay
MYLIB.aPublicMethod() // okay