State is the present arrangement of data. It is sometimes hard to remember this for two reasons:

• State means both the data in the program and the program's current point of execution and "mode".
• We build this up to be some magical thing unnecessarily.

Consider this:
"What is the process's state?" is asking about the present value of variables.
"What state is the process in?" usually refers to the mode, options, flags or present location of execution.
If you are a Turing machine then these are the same question; we have separated the ideas to give us handy abstractions to build on (like everything else in programming).

Let's think about state variables for a moment...

In many older languages you can alter state variables from whatever context you like, whether the modification of state is appropriate or not, because you manage this directly. In more modern languages this is a bit more restricted by imposing type declarations, scoping rules and public/private context to variables. This is really a rules arms-race, each language finding more ways to limit when assignment is permitted. If scheduling is the Prince of Frustration in concurrent programming, assignment is the Devil Himself. Hence the various cages built to manage him.
Erlang restricts the situations that assignment is permitted in a different way by setting the basic rule that assignment is only once per entry to a function, and functions are themselves the sole definition of procedural scope, and that all state is purely encapsulated by the executing process. (Think about the statement on scope to understand why many people feel that Erlang macros are a bad thing.)
These rules on assignment (use of state variables) encourage you to think of state as discreet slices of time. Every entry to a function starts with a clean slate, whether the function is recursive or not. This is a fundamentally different situation than the ongoing chaos of in-place modifications made from anywhere to anywhere in most other languages. In Erlang you never ask "what is the value of X right now?" because it can only ever be what it was initially assigned to be in the context of the current run of the current function. This significantly limits the chaos of state changes within functions and processes.
The details of those state variables and how they are assigned is incidental to Erlang. You already know about lists, tuples, ETS, DETS, mnesia, db connections, etc. Whatever. The core idea to understand about Erlang's style is how assignment is managed, not the incidental details of this or that particular data type.

What about "modes" and execution state?

If we write something like:

has_cheeseburger(BurgerName) ->
  receive
    {From, ask, burger_name} ->
        From ! {ok, BurgerName},
        has_cheeseburger(BurgerName);
    {From, new_burger, _SomeBurger} ->
        From ! {error, already_have_a_burger},
        has_cheeseburger(BurgerName);
    {From, eat_burger} ->
        From ! {ok, {ate, BurgerName}},
        lacks_cheeseburger()
  end.

lacks_cheeseburger() ->
  receive
    {From, ask, burger_name} ->
        From ! {error, no_burger},
        lacks_cheeseburger();
    {From, new_burger, BurgerName} ->
        From ! {ok, thanks},
        has_cheeseburger(BurgerName);
    {From, eat_burger} ->
        From ! {error, no_burger},
        lacks_cheeseburger()
  end.

What are we looking at? A loop. Conceptually its just one loop. Quite often a programmer would choose to write just one loop in code and add an argument like IsHoldingBurger to the loop and check it after each message in the receive clause to determine what action to take.
Above, though, the idea of two operating modes is both more explicit (its baked into the structure, not arbitrary procedural tests) and less verbose. We have separated the context of execution by writing basically the same loop twice, once for each condition we might be in, either having a burger or lacking one. This is at the heart of how Erlang deals with a concept called "finite state machines" and its really useful. OTP includes a tool build around this idea in the gen_fsm module. You can write your own FSMs by hand as I did above or use gen_fsm -- either way, when you identify you have a situation like this writing code in this style makes reasoning much easier. (For anything but the most trivial FSM you will really appreciate gen_fsm.)

Conclusion

That's it for state handling in Erlang. The chaos of untamed assignment is rendered impotent by the basic rules of single-assignment and absolute data encapsulation within each process (this implies that you shouldn't write gigantic processes, by the way). The supremely useful concept of a limited set of operating modes is abstracted by the OTP module gen_fsm or can be rather easily written by hand.
Since Erlang does such a good job limiting the chaos of state within a single process and makes the nightmare of concurrent scheduling among processes entirely invisible, that only leaves one complexity monster: the chaos of interactions among loosely coupled actors. In the mind of an Erlanger this is where the complexity belongs. The hard stuff should generally wind up manifesting there, in the no-man's-land of messages, not within functions or processes themselves. Your functions should be tiny, your needs for procedural checking relatively rare (compared to C or Python), your need for mode flags and switches almost nonexistant.

Edit

To reiterate Pascal's answer, in a super limited way:

loop(State) ->
  receive
    {async, Message} ->
        NewState = do_something_with(Message),
        loop(NewState);
    {sync, From, Message} ->
        NewState = do_something_with(Message),
        Response = process_some_response_on(NewState),
        From ! {ok, Response},
        loop(NewState);
    shutdown ->
        exit(shutdown);
    Any ->
        io:format("~p: Received: ~tp~n", [self(), Any]),
        loop(State)
  end.

重新阅读tkowal的回应，以了解其 * most * minimal版本。重新阅读Pascal的回应，以了解相同思想的扩展，包括服务消息。重新阅读上述内容，以了解 * 相同 * 状态处理模式的略微不同风格，并添加了输出意外消息。最后，重新阅读我在上面写的两状态循环，您将看到它实际上只是同一思想的另一个扩展。
记住，你不能在函数的同一次迭代中重新赋值一个变量，但是下一次调用可以有不同的状态。这就是Erlang中状态处理的范围。
这些都是同一个东西的变体。我想你期望有更多的东西，一个更广泛的机制或什么。没有。限制赋值消除了所有的东西，你可能习惯于看到在其他语言。在Python中，你做somelist.append(NewElement)，你现在有列表已经改变。在Erlang中，你做NewList = lists:append(NewElement, SomeList)，SomeList仍然是完全一样的，因为它曾经是。并且返回了一个包含新元素的新列表。这是否真的涉及到在后台复制 * 不是你的问题 *。你 * 不 * 处理这些细节，所以不要去想它们。这就是Erlang的设计方式，它留下了单个赋值和进行新的函数调用来进入一个新的时间片，在那里石板又被擦干净了。

The easiest way to maintain state is using gen_server behaviour. You can read more on Learn you some Erlang and in the docs .
gen_server is process, that can be:

• initialised with given state,
• can have defined synchronous and asynchronous callbacks (synchronous for querying the data in "request-response style" and asynchronous for changing the state with "fire and forget" style)

It also has couple of nice OTP mechanisms:

• it can be supervised
• it gives you basic logging
• its code can be upgraded while the server is running without loosing the state
• and so on...

Conceptually gen_server is an endless loop, that looks like this:

loop(State) ->
    NewState = handle_requests(State),
    loop(NewState).

where handle requests receives messages. This way all requests are serialised, so there are no race conditions. Of course it is a little bit more complicated to give you all the goodies, that I described.
You can choose what data structure you want to use for State . It is common to use records, because they have named fields, but since Erlang 17 maps can come in handy. This one depends on, what you want to store.

变量是不可变的，所以当你想有一个状态的演化时，你创建一个新的变量，然后用这个新的状态作为参数调用同一个函数。
这种结构是为像服务器这样的进程设计的，没有阶乘常见示例中的基本条件，通常有一个特定的消息来平滑地停止服务器。

loop(State) ->
    receive
        {add,Item}     -> NewState = [Item|State], % create a new variable
                          loop(NewState); % recall loop with the new variable
        {remove,Item}  -> NewState = lists:filter(fun(X) -> X /= Item end,State) , % create a new variable
                          loop(NewState); % recall loop with the new variable
        {items,Pid}    -> Pid ! {items,State},
                          loop(State);
        stop           -> stopped; % this will be the stop condition
        _              -> loop(State) % ignoring other message may be interesting in a never ending loop
    end