如前所述，当您的代码should NOT到达某个点(意味着那里存在错误)时，应该使用断言。在我看来，使用断言最有用的原因可能是不变量/前置/后置条件。在循环或函数的每次迭代的开始或结束时，这些必须为真。

例如，一个递归函数(两个独立的函数，一个处理错误的输入，另一个处理错误的代码，因为它很难与递归区分开来)。如果我忘记写if语句，这将很明显地显示出哪里出了问题。

def SumToN(n):
    if n <= 0:
        raise ValueError, "N must be greater than or equal to 0"
    else:
        return RecursiveSum(n)

def RecursiveSum(n):
    #precondition: n >= 0
    assert(n >= 0)
    if n == 0:
        return 0
    return RecursiveSum(n - 1) + n
    #postcondition: returned sum of 1 to n

这些循环不变量通常可以用断言表示。

assert的使用和异常的引发都与通信有关。

Assertions are statements about the correctness of code addressed at developers: An assertion in the code informs readers of the code about conditions that have to be fulfilled for the code being correct. An assertion that fails at run-time informs developers that there is a defect in the code that needs fixing. Exceptions are indications about non-typical situations that can occur at run-time but can not be resolved by the code at hand, addressed at the calling code to be handled there. The occurence of an exception does not indicate that there is a bug in the code.

最佳实践

因此，如果您将运行时发生的特定情况视为您想要通知开发人员的错误(“嗨，开发人员，这种情况表明某处存在错误，请修复代码。”)，那么请使用断言。如果断言检查代码的输入参数，当输入参数违反条件时，您通常应该在文档中添加代码具有“未定义行为”。

相反，如果这种情况的出现并不是您眼中的错误，而是您认为应该由客户端代码处理的(可能很少，但可能)情况，则引发异常。引发哪种异常的情况应该是相应代码文档的一部分。

有没有演出[…]使用assert时的问题

断言的计算需要一些时间。但是，它们可以在编译时被删除。然而，这有一些后果，见下文。

有[…]使用assert的代码维护问题

Normally assertions improve the maintainability of the code, since they improve readability by making assumptions explicit and during run-time regularly verifying these assumptions. This will also help catching regressions. There is one issue, however, that needs to be kept in mind: Expressions used in assertions should have no side-effects. As mentioned above, assertions can be eliminated at compile time - which means that also the potential side-effects would disappear. This can - unintendedly - change the behaviour of the code.

"assert"语句在编译优化时被删除。所以，是的，它们在性能和功能上都有差异。

在编译时请求优化时，当前代码生成器不会为assert语句生成代码。Python 3 Docs

如果您使用assert来实现应用程序功能，然后优化部署到生产环境，那么您将受到“但它在开发中有效”缺陷的困扰。

参见PYTHONOPTIMIZE和-O -OO

是否存在性能问题?

Please remember to "make it work first before you make it work fast". Very few percent of any program are usually relevant for its speed. You can always kick out or simplify an assert if it ever proves to be a performance problem -- and most of them never will. Be pragmatic: Assume you have a method that processes a non-empty list of tuples and the program logic will break if those tuples are not immutable. You should write: def mymethod(listOfTuples): assert(all(type(tp)==tuple for tp in listOfTuples)) This is probably fine if your lists tend to be ten entries long, but it can become a problem if they have a million entries. But rather than discarding this valuable check entirely you could simply downgrade it to def mymethod(listOfTuples): assert(type(listOfTuples[0])==tuple) # in fact _all_ must be tuples! which is cheap but will likely catch most of the actual program errors anyway.

无论如何，如果你处理的代码依赖assert来正常工作，那么添加以下代码将确保assert被启用:

try:
    assert False
    raise Exception('Python assertions are not working. This tool relies on Python assertions to do its job. Possible causes are running with the "-O" flag or running a precompiled (".pyo" or ".pyc") module.')
except AssertionError:
    pass

在诸如PTVS、PyCharm、Wing assert isinstance()等IDE中，可以使用isinstance语句对一些不清楚的对象启用代码补全。